A year into building Phantix, it’s worth writing down what we’ve actually learned. Not the polished version — the honest one.
The Speed Is Real, But So Is the Mess
AI tools have genuinely compressed our development timelines. Code that would have taken days takes hours. Prototypes that would have taken a sprint take an afternoon. The productivity gains are real and they compound — a faster feedback loop means more iterations, which means better products sooner.
But speed creates its own problems. When you can build faster, you can also make mistakes faster. The tendency is to ship before you’ve validated whether you’re building the right thing. We’ve done this. We’ve built features quickly, shipped them, and then had to unpick them because we moved before we understood the problem clearly enough.
The lesson: AI doesn’t change the importance of understanding what you’re building. It just reduces the excuse for not having something working to show.
Building on Moving Ground
AI capabilities are changing fast. The model you integrated with six months ago may have been superseded. The API behavior you built against may have changed. The cost structure that made your pricing viable may no longer hold.
This is a real risk that doesn’t get talked about enough. Building a SaaS product on top of AI infrastructure is building on moving ground. The foundation shifts under you, sometimes slowly and sometimes suddenly.
We’ve had to rebuild integrations after model updates changed output behavior. We’ve had to revisit our assumptions about what the AI could reliably do after discovering edge cases that weren’t edge cases at all — they were common user behaviors we hadn’t anticipated.
The practical response is to build abstraction layers that isolate your AI dependencies from your core logic. Your product’s value should be in what you do with the AI, not in the AI itself. If the model changes, you need to be able to swap it without rebuilding everything around it.
The Importance of Focusing on the Problem
There’s a temptation in AI product development to lead with the technology. “We use GPT-4 to…” or “Our AI can…” The problem is that users don’t care about the AI. They care about their problem.
When we talk about Mentomate, we don’t talk about language models. We talk about homework battles. We talk about the moment a parent realizes their child has been copying from ChatGPT instead of learning. We talk about what it feels like to have your evenings back.
The AI is the how. The problem is the why. If you can’t describe your product without mentioning AI, you probably haven’t understood the problem well enough yet.
This sounds obvious, but it’s easy to lose sight of when you’re deep in the technology. The interesting technical challenges are genuinely interesting. Prompt engineering, context management, output reliability — these are hard and engaging problems. But they’re means, not ends.
What We’d Do Differently
More user research before writing code. We made assumptions early on about what users needed that turned out to be partially wrong. AI tools make it easy to build quickly, which makes it tempting to build before you’ve validated. This is backwards.
Smaller initial scope. Our first versions tried to do more than they needed to. The features we thought users would want in month one often weren’t the features they actually used. Start with the minimum that delivers the core value. Add complexity only when users ask for it and you can see clearly why.
Better instrumentation from the start. Understanding how users actually behave inside your product — not how you think they’ll behave — is worth investing in early. We added proper analytics too late and had to make decisions based on incomplete data for longer than we should have.
The Honest Summary
Building with AI is genuinely better than building without it. Faster, cheaper, more capable. The tools we can build today weren’t possible a few years ago, and that’s exciting.
But the fundamentals of good product development haven’t changed. Understand the problem. Validate before you build. Focus on what matters to users, not what’s technically interesting. Be honest about what your product actually does.
AI amplifies what you put in. If you put in clear thinking about real problems, you get good products faster. If you put in fuzzy thinking about vague problems, you get a sophisticated mess faster.
The technology is not the hard part.
