Mistakes I Made Developing SaaS for My Clients

Over the past two years, working with software development and no-code or low-code tools, I have come across a bunch of challenges. These issues were essential for the growth of my software house, and I want to share with you what I’ve learned from it all.

Mistake No. 1 - I Didn’t Talk To The Product’s End Users

Many times, I was so focused on what the client wanted and what I already knew that I forgot about the most important aspect: understanding what the end users truly needed. The solution was pretty simple: I began to genuinely talk with the people who were going to use the product, conducting surveys to learn about their real necessities.

I recommend creating questionnaires to validate your ideas, but it’s important to ask questions that really bring the insights you need, instead of just vanity metrics (What do you think of this idea? Would you use this product?). Put personal impressions aside; what matters are the actions and feelings of those who will use your software. Questions should always focus on the user persona (How do you feel when faced with problem X? How do you attempt to solve it?).

Mistake No. 2 - I Skipped The User Journey Map

Before, I used to dive into development or making prototypes without proper planning. The result? Users got confused and abandoned the platform. Now, after defining the problem and having some idea of the solutions, anticipating every step a user will take until they get what they want has become the rule.

To give a quick example, here’s a user flow for a food order:

  • Already have an account? Then, log in. Don’t have one? Create it.
  • Accept the Terms of Use.
  • Choose the restaurant.
  • Decide on the dish.
  • Customize your order.
  • Input your delivery address.
  • Inform your payment method.
  • Confirm the payment.
  • Wait for the delivery.
  • Give feedback to the restaurant.

Mistake No. 3 - I Developed Without Creating a Prototype

Back then, I would start developing as soon as I heard the client’s idea, which cost me hours on projects that never moved forward.

I realized that creating a prototype first, even better if it’s on Figma, is a step that can’t be skipped. Discussing the project and being able to easily change things before going into development is gold. If you don’t have the budget or knowledge to use Figma or hire someone, make a draft on paper, but it should already give you an idea of interactive elements and their placement.

Mistake No. 4 - I Aimlessly Managed Projects

Previously, I relied a lot on intuition, but I learned that without a well-defined plan and organization, it doesn’t work out. It’s vital to know who is doing what, when, and how.

Tools like ClickUp or Trello are incredibly helpful in managing what needs to be done and when.

Mistake No. 5 - I Tried To Be a One-Man Army

I thought I could handle delivering amazing projects on my own or with another freelancer. It didn’t go very well, and there was a good dose of frustration and mess.

So, what did I do? I set up and started coordinating teams for each project, with Product Managers, UX Designers, and Devs, each with their task and responsibility. It may seem expensive at the start, but the medium to long-term benefits are much greater than the initial costs, and the return on investment (ROI) is much higher.

These were some mistakes I made and managed to solve.

What about you, what mistakes have you made and resolved? Share in the comments.


Good text, thanks @oxeapps.

These ones you mentioned, some others I heard and experienced prove that when it comes to clients, the problems of no-code and custom code are the same :slight_smile: Bubble makes some part of the app creation faster, but as Fred Brook noted in his seminal article No Silver Bullet: Essence and Accidents of Software Engineering:

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

This is a good read for everyone in the software business, especially those of you no-coders who would like to understand the history of software engineering a little better. You can find a copy here. It has some outdated parts but still mostly universal :+1: