Almost every software product we’ve ever worked on started the same way: somebody noticed
a problem and thought “there has to be a better way to do this.” A frustrating internal process, a
customer complaint that kept coming up, a spreadsheet held together with formulas nobody
wants to touch anymore. That part is easy. Everybody has ideas.
The hard part — the part that actually separates a product from a napkin sketch — is everything
that happens between “I have an idea” and “people are using this and, ideally, paying for it.”
That gap is where most of the real work lives, and it’s also where most projects either find their
footing or quietly go sideways.
This isn’t a theoretical framework. It’s roughly the path we walk founders and business owners
through when they come to us with an idea and not much else — which happens more often
than you’d think.
Start with the problem, not the feature list
The single most common mistake we see is a founder walking in with a feature list instead of a
problem statement. “I want an app with user profiles, payments, notifications, a dashboard, chat,
analytics, and some AI in there somewhere.” That’s not a product. That’s a shopping list, and it
tells us almost nothing about who needs this or why.
What we actually want to know is who has the problem, what the problem is, how they’re solving
it today, and why that current solution isn’t good enough. Take inventory management for small
retailers. “I want to build an inventory app” isn’t a starting point. “Small retailers running two or
three locations are tracking stock across spreadsheets that don’t talk to each other, so nobody
actually knows what’s in stock until someone manually checks” — that’s a starting point. It
names a user, a behavior, and a specific cost of the status quo. Everything downstream gets
easier once you have that.
Validate before you build anything
Before any development happens, it’s worth finding out whether the problem is actually as
painful as it feels from the inside. Talk to the people who’d supposedly want this. Ask how they
handle the problem today, what’s annoying about it, how often it comes up, and what it costs
them — in time, in money, in headache.
The trap here is asking “would you use an app that does X?” Almost everyone says yes to that
question, because agreeing costs nothing and people are generally polite. A much more useful
question is “how do you currently deal with this?” — because what someone actually does tells
you far more than what they’d hypothetically do. If people have already built workarounds, hired
someone, or are paying for a clunky alternative, that’s a real signal. If they shrug and say it’s not
really a big deal, that’s a signal too, just not the one you were hoping for.
Validation isn’t a guarantee of success — plenty of validated ideas still fail for other reasons —
but skipping it is how a lot of teams end up spending months building something that, it turns
out, nobody particularly wanted.
Get specific about who you’re building for
“Small businesses” is not a target user. It’s too broad to make a single useful decision from.
“Independent retail stores with two to ten locations currently managing inventory in
spreadsheets” is specific enough to actually build against — you can ask what their workflow
looks like, what devices they use day to day, what would get them to switch from what they’re
doing now, and what they’d realistically pay.
You don’t need to understand your entire eventual market before writing a line of code. You
need to understand this one group well enough to build something they’d actually use. Everyone
else can come later.
Say what the product does, in one sentence
Once the problem and the audience are clear, you should be able to describe the product itself
without reaching for buzzwords. A useful description answers three things: who it’s for, what
problem it solves, and why it beats what they’re doing now.
“Helps multi-location retailers track inventory in one place instead of juggling spreadsheets, so
managers can actually see what’s in stock across every store” does real work. “An innovative
next-generation inventory management solution” does none — it’s the kind of sentence that
could describe almost anything, which means it doesn’t really describe this thing at all. If you
can’t say plainly what the product does, it’s usually a sign it’s too early to start building it.
Figuring out what actually belongs in the first version
This is where a lot of otherwise well-planned projects quietly go off the rails. The idea starts
small — a simple booking tool, say — and then somewhere along the way a customer portal
turns into a mobile app, someone suggests an AI assistant, analytics gets added, then a few
integrations, then an admin dashboard nobody asked for yet. None of these are bad ideas in
isolation. The problem is that the “minimum viable” part quietly disappears, and six months later
the team is still building version one.
An MVP isn’t a lower-quality product. It’s a deliberately narrow one — the smallest set of
functionality that actually delivers the core value and lets you learn something from real users.
For an appointment-booking platform, that’s probably registration, business profiles, availability,
booking itself, and email notifications. It’s probably not a native mobile app, loyalty programs, AI
recommendations, or ten integrations on day one — not because those are bad ideas, but
because none of them help you find out whether the core idea works.
We’ve had clients push back on this — understandably, because it can feel like you’re shipping
something incomplete. But an MVP that does one thing well and gets real usage teaches you
more in a month than a fully-loaded product that took a year to build and nobody’s tested yet.
Walk through it before you build it
Before development starts, it’s worth actually mapping how someone moves through the
product — landing page, sign-up, account setup, first real action, whatever the equivalent of
“customer books an appointment” is for your product, notification back to the business. Laying
this out on paper, even roughly, surfaces gaps that are cheap to fix now and expensive to fix
later, once code has been written around the wrong assumption.
Simple wireframes are usually enough at this stage. You’re checking that the flow makes sense,
not finalizing what anything looks like.
The technology decisions, and why timing matters
Once the scope is reasonably settled, the technical questions start: web, mobile, or both; what
the backend and database should look like; what third-party services you actually need for auth,
payments, and anything else; hosting; and how the system needs to handle growth. This is
genuinely where an experienced development partner earns their keep — early technology
choices are some of the more expensive things to unwind later if they turn out wrong.
That said, there’s a failure mode on the other side too: over-engineering a version one that
doesn’t need it yet. We’ve seen teams spend real budget building for a scale they’re nowhere
near reaching, when that same money would have been better spent getting the actual product
in front of actual users. The right approach is technology that comfortably fits what the product
needs today, with a sensible enough foundation that it doesn’t have to be rebuilt the moment
things start working.
Design isn’t a finishing touch
A product can work technically and still fail because it’s frustrating to use. Good UX isn’t
something bolted on at the end — it starts from understanding what someone’s actually trying to
accomplish and making the important actions obvious, with as few unnecessary steps as
possible.
Clickable prototypes are worth the time here. Putting something in front of a handful of potential
users before a single feature is built can surface real confusion — the kind that’s cheap to fix on
a prototype and considerably more expensive to fix after development.
Building in pieces, not all at once
Development itself usually moves through planning, design, build, test, and deployment, but
rarely as one long unbroken push. Breaking it into smaller iterations means the team — and the
business stakeholders footing the bill — can see progress, catch problems early, and adjust as
the product actually takes shape, rather than finding out three months in that priorities have
shifted.
The point of this stage isn’t clearing a ticket backlog. It’s producing something that actually
solves the problem that started this whole process.
Real users will surprise you
Internal testing catches a lot, but it never catches everything. Real users misuse features in
ways nobody anticipated, ignore things the team considered central, stumble into workflows that
were never designed, or ask for something nobody thought of. All of that is useful — arguably
more useful than anything gathered before launch, because it’s grounded in actual behavior
instead of assumptions.
Getting an MVP in front of a controlled group of early users, watching how they actually use it,
and paying attention to where they hesitate or drop off tends to teach a team more in a few
weeks than months of internal planning would.
Launch is the start, not the finish
It’s worth saying plainly: shipping the MVP doesn’t close the project, it opens the next phase of
it. Once real people are using the product, there’s something far more valuable to work from
than assumptions — actual evidence. Are people completing the core workflow? Which parts
are getting used, and which are being ignored? Where does drop-off happen? Would people
actually pay for this?
The next version should be shaped by those answers, not by whatever features felt exciting
during the planning phase six months earlier. Build, launch, measure, learn, improve — and
then do it again. That loop tends to produce a better product than trying to predict every
requirement up front ever could.
More features rarely means more value
One of the more counterintuitive lessons in this work is that a product with twenty features that
solves a real problem well tends to beat a product with a hundred features that nobody fully
understands. Feature count feels like progress, and it isn’t always. Solving the actual problem is
progress. Everything else is a bet, and most of those bets are better placed after you have real
usage data to place them with.
Where this actually starts
Turning an idea into working software is never purely a development exercise. It pulls in
business strategy, customer research, product decisions, design, engineering, testing, and a fair
amount of listening to people who aren’t you. The technology is one part of that — an important
part, but not the whole thing.
If you’ve got an idea and not much beyond that, you don’t need a finished technical spec before
talking to anyone. You need to be able to explain the problem clearly. The rest — scoping an
MVP, working out the technical requirements, mapping a realistic path to launch — is usually
easier to figure out in conversation than alone in front of a blank document.
At Kerss Technology, this is more or less where most of our work starts: an idea, a real problem
behind it, and a first version worth building.