"We need custom software" sounds, to most small and medium businesses, like a three or four month project. Discovery meetings, a requirements document, approvals, a timeline with milestones, and only then, eventually, something usable.
It doesn't have to be that way. Most systems that solve a real problem for a small business - not a platform built to scale, a specific system - can be built and delivered in two to six weeks. The difference isn't magic or a bigger team. It's what gets cut.
What makes a project long isn't the code
Writing the logic of a system - the CRUD, the validations, the payment integration, the admin panel - rarely takes months. What stretches projects out is everything around the code: weeks of discovery before writing the first line, a scope document reviewed several times before it's approved, layers of approval where every change passes through two or three people before touching the project.
None of that builds the system. It only delays it. In a consultancy with structure, those layers exist because there's a lot of people to coordinate. In a one-person project backed by AI, those layers simply don't exist - there's no one to coordinate.
Short discovery, not zero discovery
Cutting the timeline down doesn't mean skipping the step of understanding the problem. It means not turning that step into a project of its own. One or two conversations to understand what's really needed - not what the client thinks they need, but the underlying problem - are enough to get started. The rest of the scope gets defined while the system is already being built, not before.
That flips the usual order: instead of documenting everything before building anything, a working first version gets built fast, and gets adjusted from there. It's easier to fix something you can already see and use than to fix a document.
Weekly iteration, not a single delivery at the end
A three-month project usually has one delivery: at the end. Until that point, the client hasn't seen anything working, just mockups or documents. If something was misunderstood, it's discovered late, when it's already expensive to fix.
A two-to-six-week project works the other way: something is up and running from the first week, even if it's a minimal version. Every step gets shown as soon as it exists. If something isn't what the client expected, it gets fixed in days, not at the final review of a three-month project.
What gets cut and what doesn't
Shortening the timeline doesn't mean doing things faster and worse. It means removing what doesn't add value to the final result:
- Exhaustive documentation nobody reads again once the system works.
- Status meetings that exist to coordinate people, not to move the work forward.
- Chains of approval, where every step adds days without adding a decision.
- Separate phases for design, development, and testing, instead of doing it together.
What doesn't get cut is judgment: understanding the problem well before solving it, taking extra care wherever money or stock is at stake, and testing that it works before calling it done.
What this doesn't apply to
This works for specific systems: a catalog, a booking system, a checkout, a reporting dashboard. It doesn't apply the same way to a platform meant to scale to thousands of users from day one, or a project that needs to integrate with several legacy systems at once. There, more upfront design time is actually needed, because architecture mistakes are much more expensive to fix later.
Most small businesses, though, aren't in that situation. They need to solve a concrete problem, not build a platform. And for that, three months is no guarantee of a better result. Often, it's just time lost in the middle.