Ask how long a custom app takes and most developers will give you a number that assumes everything goes well. Everything does not go well. Here's a timeline built on how projects actually run.
Weeks 1–2: Working Out What You're Building
This is the part businesses want to skip and shouldn't.
The goal isn't a specification document nobody reads. It's a short, specific description of what someone does in the software, step by step, and what happens when they do something unexpected.
Most of the cost overruns we've seen trace back to this fortnight being rushed. Requirements that surface in month three cost several times what they'd have cost in week two, because by then things have been built on top of the wrong assumption.
Your involvement here is heavy. Expect real meetings and real decisions. Nobody can do this part for you.
Weeks 3–4: Design and Structure
Screens get designed. The data model gets worked out — what information the system stores and how the pieces relate.
The data model is invisible and it's the thing that determines whether the software can grow later. Get it wrong and every future feature fights it.
You'll see designs at this stage. Say what you don't like now, loudly. Changing a screen design is cheap. Changing built software is not.
Weeks 5–12: Building
The longest stretch, and the quietest. Expect to see working pieces regularly rather than one big reveal — if a developer goes silent for six weeks and promises to show you everything at the end, that's a warning sign.
Two things reliably eat time here that nobody plans for: connecting to systems you don't control, and the edge cases. What happens when two people edit the same record? When someone's card is declined halfway through? When the file is 400MB?
Edge cases are most of the difference between "it works in a demo" and "it works."
Your involvement is lighter but not zero. You'll be answering questions weekly. Slow answers slow the project.
Weeks 13–14: Testing With Real People
Not the developers testing. Actual users doing actual work.
They will do things nobody imagined. That's the point. This is where you find that the workflow you described isn't quite the workflow people follow, and it's much better to learn it now.
Budget time to fix what this finds. A testing phase with no fixing phase after it is decoration.
Week 15: Launch
Launch itself is usually undramatic if the previous fourteen weeks were done properly. Data gets moved across, people get shown how it works, and you keep the old process running alongside for a short while.
If you're going native, add two to three weeks for app store review — and know that a rejection means going round again.
The Honest Total
Three to four months for a focused first version, assuming:
- You can make decisions quickly
- One person on your side owns it
- Scope doesn't grow mid-project
- Nothing depends on a third party who's slow
Change any of those and it stretches. The single biggest accelerator is having one decision-maker with authority. Projects with a committee take substantially longer, and it's almost never the developers who are the bottleneck.
What Makes It Take Longer
- Adding features mid-build. The most common cause by a distance.
- Slow feedback. A week to answer a question is a week added.
- Unclear ownership. Three people with opinions and nobody deciding.
- Waiting on someone else's system. Their timeline becomes yours.
- Perfection before launch. Version one doesn't need to be everything.
What Happens After
The timeline doesn't end at launch. Plan for a burst of small fixes in the first month as real use surfaces real problems, then ongoing maintenance indefinitely.
We build software for businesses in Bethlehem, Allentown, Easton and across the Lehigh Valley, and we'd rather tell you three to four months honestly than six weeks optimistically. If you want a realistic read on your project, let's talk it through.