The short answer
Most custom software projects for small businesses take 1 to 2 weeks for a simple informational site, 2 to 4 weeks for a focused internal tool, and 2 to 6 months for a full business platform. The timeline is mostly decided by integrations and decision speed, not raw build time.
Those numbers assume a small, focused team — one or two senior developers rather than a handoff chain across a five-person agency — a clear scope, and a client who can answer a question inside a day or two. Miss any of those and every band roughly doubles. The rest of this post walks through the timeline bands by project size, where the hours actually go, and what makes schedules slip.
Timelines by project size
Timelines track the pricing bands almost one to one. A bigger budget buys more screens, more integrations, and more decisions — and each of those takes time.
- Simple informational website (under $1,000): 1–2 weeks. A few pages, a contact form, basic SEO, no integrations, no user accounts. Most of the elapsed time goes to copy approvals and photography, not code.
- Polished marketing site ($1,000–$5,000): 2–3 weeks. Custom design, a small CMS or blog, maybe a CRM-wired contact form or a calculator. Content and design revisions are the long tail.
- Focused internal tool ($5,000–$15,000): 2–4 weeks. A single-purpose automation, small client portal, or lightweight two-system integration. Build time is quick; the integration auth and data mapping are where days get spent.
- Full business platform ($15,000–$50,000): 2–6 months. Authentication, admin controls, a real data model, two to five integrations. The variance inside this band is almost entirely explained by the integration list and the client's decision speed.
- SaaS-scale project ($50,000+): 6 months or more, typically with an ongoing retainer after launch. Multi-tenant data, a larger feature surface, and an extended stabilization period. Phase this into milestones, not one big ship date.
Two projects at the same price band can ship weeks apart. A $12,000 internal tool that reads from a modern public API with OAuth ships in three weeks. The same-sized tool that has to pull data out of a legacy on-premise system with a brittle export takes six. The sticker price didn't change — the integration did.
Where the time actually goes
Inside a given timeline, most of the hours split across six phases. Pythn's five-stage process maps directly onto them.
- Discovery (1–3 days): a free 30–45 minute call plus a 48-hour written summary. Nothing is built here — the goal is to confirm the scope is real and the economics make sense.
- Design (3–10 days): the written design document — screens, data model, integrations, auth model, edge cases. Fixed scope and fixed price are locked at the end of this phase. For a small internal tool this is two or three days; for a full platform it can run a full two weeks, and the time is well spent. Every hour here is worth five hours later.
- Build (50–70% of the total timeline): the actual engineering. Focused increments, weekly demos, staging deployments the client can click through between calls.
- Test (10–15%): integration tests against production APIs in sandbox mode, user-acceptance testing with the client, bug fixes. Cheap if done continuously through the build phase, expensive if saved for the end.
- Launch (1–3 days): DNS, production secrets, final database migration, smoke test. Usually short; occasionally the longest single day of the project — see "deployment blockers" below.
- Handoff and training (1–5 days): team training, monitoring and alerting setup, written runbook. Pythn includes 30 days of post-launch support in every engagement to catch the issues that only surface once real users hit the system.
The pattern worth noticing: design and handoff are often underestimated, and the build phase gets compressed to compensate. A full platform with a rushed design phase almost always overshoots the original timeline, because decisions that should have been made on paper end up getting made — and re-made — in code.
Four things that stretch a timeline
Across most small-business custom software projects, the same four issues explain nearly every delay. None of them are about raw developer speed.
1. Scope creep
The classic. Something ships, the client sees it working, and a new idea is obvious — "while we're in there, can we also add...". Individually each addition is small. Collectively they can double a timeline. The cure isn't saying no; it's writing down the new request, pricing it as a change order, and letting the client decide whether to absorb the delay now or defer it to phase 2. Fixed scope isn't about rigidity. It's about making the delay visible so the tradeoff is a conscious choice.
2. Integration surprises
Every small-business custom software project touches at least one external system, and external systems misbehave. Rate limits that aren't documented, sandbox data that doesn't match production, OAuth scopes that require vendor approval, webhook payloads that omit a field present in the docs. The $2,000–$5,000 surcharge Pythn quotes per integration is real, and most of that cost is time rather than code — waiting for sandbox credentials, chasing a support engineer, confirming what the API actually returns in edge cases.
3. Stakeholder latency
This is usually the single biggest slip factor and the least talked about. A build gets blocked waiting on a decision — which payment processor, which field layout, who approves the copy — and the blocked state costs a full day even when the decision itself takes ten minutes. Projects with one clear decision-maker ship on time. Projects where three stakeholders have to agree before any choice is final usually don't.
4. Deployment blockers
The last-mile problems: DNS that someone else's vendor controls, API credentials from an ex-employee's login, a Stripe account that still needs to be verified, a mobile app sitting in App Store review. These are administrative rather than technical, and they show up on launch day because nobody thought to check them during design. A deployment-blocker audit two weeks before launch — explicitly walking the credential, DNS, and vendor-approval list — catches almost all of them in time.
How to finish faster without cutting corners
Timelines compress in a few predictable ways without sacrificing quality.
- Ship a smaller first scope. The biggest timeline lever is scope, not speed. A $12,000 build in four weeks is almost always better than a $30,000 build in four months — you learn more from real users in four weeks than from an extra round of design.
- Name one decision-maker. Not a committee. One person with authority to approve scope, copy, and design within a day. This usually cuts total elapsed time by 20–40% with no change to build hours.
- Gather credentials and access up front. API keys, OAuth client IDs, DNS admin access, sandbox accounts — ask for all of it in week one. Credentials that arrive on week six are the most expensive delay in the whole process.
- Accept a less-custom version of commodity parts. Use a standard login screen, a standard admin CRUD page, a stock email template. Save the custom design for the parts of the product that actually differentiate the business.
- Prefer a web app or PWA over native mobile. Web and PWA timelines are roughly 30–50% shorter than native mobile builds for most small-business use cases, and App Store approval alone can eat a week on a native project.
Frequently asked questions
Can you build custom software in a week?
Yes, for a narrow scope. A simple informational website, a single-form intake tool with no integrations, or a one-page landing page with a calculator all fit in a week with a focused team and a client who can approve copy quickly. What doesn't fit in a week is anything with authentication, an integration that requires vendor approval, or more than a handful of screens. If a shop quotes a full business platform in a week, they've almost certainly left out the parts that actually take time.
What causes software timelines to slip?
Four things, in rough order of frequency: stakeholder latency (decisions sitting in someone's inbox), scope creep (new features added mid-build), integration surprises (external APIs behaving differently than their docs suggest), and deployment blockers (DNS, credentials, vendor approvals discovered only at launch). Raw developer speed is almost never the bottleneck. The strongest predictor of a project landing on its original timeline is whether the client can make decisions inside a 24-hour window.
How long does a mobile app take compared to a web app?
A native mobile app typically takes 30–50% longer than a comparable web app or progressive web app, plus an extra 5–10 days for App Store and Play Store review on top. For most small-business software, a web app or PWA is the faster and cheaper default. Native mobile is worth the extra time when the app genuinely needs offline mode, background push notifications, or deep hardware access like Bluetooth or the camera.
Why do big-agency timelines usually run longer?
Two reasons. First, every handoff between project manager, designer, and developer costs a day of elapsed time even when the work itself is quick. Second, approval gates — internal review, account-manager sign-off, change-control boards — add structure that a small shop simply doesn't have. For a small-business project, a two-person senior team usually ships in roughly half the elapsed time of a five-person agency team doing identical scope.
Does the discovery call count toward the timeline?
No. Discovery is free and unmetered — it exists to figure out whether the project should happen at all. The official timeline starts the day the design document is signed and the scope is locked. Anything before that is negotiation, not a build commitment.