More often, we are getting requests from people who have actually built their SaaS system with AI. Sometimes it’s lovable; other times, it’s a Copilot like Claude. The usual request from this type of client is to stabilize the system, because it is neither scalable nor are users leaving because of too many issues that our clients cannot fix with AI.
While it is amazing that some system even have their first users, the common problem is not only the code, but the entire system structure. As I see it for now, self-build systems have common issues:
- The system is overcomplicated.
- The system is built for too many user roles.
- The system is supposed to achieve many goals.
- The overall UI/UX is very poor.
- Systems have many bugs.
- AI does not use optimal tech solutions.
- The code is messy and very hard to maintain.
Basically, if the client is not a professional product designer, they will make all the standard software product mistakes. And this is not about code yet, it’s about the user problems, goals, and how we solve them with tech.
Our flow that helps to fix the problem:
1. Define the problem you want to solve.
Working software is not enough to build a successful business. If your software doesn’t solve any problem, or the problem is already solved, or, for example, your software solves too many problems. It won’t succeed in the market, so you need a very clear understanding of the problem you are solving.
2. Define the critical user.
You may be solving a good problem, but your audience is not ready to pay for the solution, or, for example, doesn’t have enough money to pay for it. For example, if you’re building something for students, I’m quite confident that this group will be able to find a free version of your solution.
3. Search for competitors.
Sometimes your competitors are doing a great job and offering a good product. They have amazing marketing and charge a very low price for good software, so if you plan to build something similar, you have a very low chance of success.
4. Brainstorm on the optimal solution.
I always recommend involving a professional for such brainstorming sessions, as they will help find the right path to success. Sometimes it can be your friend. Sometimes you can find a good expert to hire for several hours.
5. Design your system well – (UI/UX + Architecture)
Similar to the previous item, I believe that a professional product designer or product architect should be involved at this stage. After understanding the problem, they will use the most suitable technology and flow to solve the problem.
As a result of this stage, I would expect you to have a very solid specification of your MVP. This should include the system architecture and the technology to be used. modules you want to build, the user stories related to those modules, and the acceptance criteria for each user story. Just perfect if you can also make UI/UX design of a system.
6. Build a solid MVP fast.
You can build the first prototype on your own with the help of AI, or you can hire a team of professional developers. It depends on your budget capabilities, but it does not really matter at this stage. My recommendation is not to overspend on your first MVP because most probably changes will come.
At this stage, having a strong professional specification and a well-designed UI/UX for your MVP will help you build a solid system faster, without spending too much time on it. You can follow the standard approach: “think first, build later.”
7. Test your MVP version on the market.
Usually, we spend 3 to 6 months building an MVP and another 3 to 6 months testing it in the market. Feedback from potential users and current users is very helpful for prioritizing your next steps on the roadmap.
However, I see many players on the market who build systems just for fun, like non-professional artists making their own paintings. They do it for self-expression, not for business. Everything is fine with this approach, as long as you understand your goal. But if you ever want to make money from it, you should test your market and audience.
8. Stop or Reiterate.
You need to talk to at least 20 people and collect their feedback regarding the system you are building. If they are not positive regarding your solution. I would recommend that you stop right away. But if they are willing to spend and use your system, even though it is not perfect, this is a good signal for you. You should move forward.
Offer from LaSoft Team
If you’re building a system and you feel like you don’t know where to start, how to write a spec, how to make your first system design, or how to fix backend issues or push your system to production. Please drop us a line at info@lasoft.org, and we will help you.
