What We Learned Building Our First SaaS

Building Socratic, our first internal SaaS product, has been an education in humility. Not the kind where you fall flat on your face — the kind where you slowly realise how many things you thought you understood that you actually did not.

Here is what the process taught us.

Start with the problem, not the solution

The original pitch for Socratic was: "an AI chatbot that answers questions." But there are a thousand of those. What made us stop and rethink was asking the harder question: what is the actual problem people have?

Turns out, people do not need more answers. They need to understand. There is a gap between being told something and actually getting it — and most chatbots skip straight to the telling. That is why we pivoted to a Socratic method approach: guide users toward understanding through questions and structured dialogue rather than handing them a paragraph.

Feature creep is a spectrum, not a binary

You hear "avoid feature creep" a lot. What nobody tells you is that it is not about saying no to everything. It is about knowing which features actually serve the core experience and which ones are just noise you use to avoid shipping.

We cut:

Dashboard analytics — nobody needs charts before they have users
Multi-language support — important, but not for v1
Team collaboration — single-user first, figure out groups later

We kept:

Conversation threading — core to the experience
Difficulty adaptation — the Socratic method only works if the questions match the user level
Session export — people want to save their learning journey

Launch before you are ready

We held Socratic back for weeks because "it is not polished enough." Polished is a trap. The version we launched had rough edges. The UI was not perfect. Some edge cases crashed the session.

And you know what? Early users did not care. They cared that it worked — that the core idea resonated. The feedback they gave us shaped the next iteration far more effectively than any amount of internal deliberation could have.

If you are not embarrassed by your first release, you launched too late. — Reid Hoffman

The tech choices matter less than you think

We spent weeks debating the backend architecture. Monolith vs microservices? PostgreSQL vs SQLite? React vs vanilla?

In hindsight, it barely mattered. What mattered was that we shipped. Technology choices constrain you over years, not months. A well-organised monolith you can refactor later beats a perfectly-modular microservice architecture that never gets launched.

Our stack ended up being straightforward: React frontend, Python backend, PostgreSQL. Nothing fancy. But it works, it is fast, and we understand every line.

What we would do differently

Talk to users earlier. We waited until we had a working prototype. Should have done it with wireframes.
Scope the MVP tighter. Even after cutting, we still launched with too much. A single conversation thread and one subject area would have been enough.
Charge money from day one. Free users give polite feedback. Paying users tell you what is actually broken.

Where we are now

Socratic has a small but engaged user base. The feedback loop is running. We are iterating weekly, not monthly. And we have stopped treating it as "the product" — it is the first version of a product that will look very different in a year.

The biggest lesson: building software is easy. Building something people need is hard. But it is the only thing that matters.