How We Scope a Custom Software Project in 48 Hours

Why We Run a 48-Hour Scoping Sprint

We scope every qualified custom software project in two days because the alternative is worse for everyone. Long discovery phases drain founder momentum. Skipping discovery altogether is how you end up four times over budget. Our 48-hour sprint produces a written scope, a feature priority list, a milestone timeline, and a price the founder can sign off on — fast enough to keep deal momentum, structured enough to protect the build.

The sprint is free. It follows a 30-minute consultation call, runs on us, and produces a document the founder owns and can take anywhere. We do this because we only build projects above ₱500,000 in build value, and at that scale a tightly-scoped engagement is worth far more to both sides than a fee on the front-end. If the founder doesn't move forward with the build, we shake hands and they keep the document.

This post is the exact playbook. What we do, when we do it, what we deliver, and what we've learned from running it on dozens of client projects.

---

The Cost of Not Scoping

Before the playbook, the math. The latest research on software project outcomes is brutal: only 31% of projects deliver on time, on budget, and on scope. Of the projects that fail, 52% fail because of scope creep — making it the single most common root cause of project failure, ahead of bad estimates, technical debt, or team turnover. The Project Management Institute attributes 37% of project failures directly to unclear objectives and milestones — exactly the gaps a scoping phase exists to close.

The cost story is just as stark. 62% of projects experience budget overruns, mostly from uncontrolled scope expansion, and scope creep on an unscoped project can cost up to four times the original budget. On the flip side, teams that run a structured discovery phase before build report 20–40% cost reductions versus comparable unscoped projects.

Two days is cheap insurance. That's the whole argument.

---

What "Scope" Actually Means

A software project scope is the set of features, integrations, performance requirements, non-functional constraints, and explicit exclusions that define what will be built and what won't. It's not a wishlist. It's a contract between founder intent and engineering reality, written down before either side commits to a price or a timeline.

Three things consistently get confused with scope, and getting these straight is half the battle:

• Vision is what the product becomes in three years. It informs scope but isn't scope.
• Roadmap is the sequence of releases over time. Scope is what's in v1 specifically.
• Spec is the implementation detail — the API contracts, database schema, component breakdown. Spec is what comes after scope is locked.

We scope v1. We sketch the roadmap. We write the spec only after the founder signs off on scope, because writing detailed specs for features that get cut is the most common form of wasted discovery hours we've seen.

---

The 48-Hour Sprint

Here's the actual hour-by-hour. We've run this enough times that the rhythm holds across project types — internal tools, customer-facing apps, ERPs, mobile builds. The whole thing happens after a 30-minute consultation call where we confirm the project fits our ₱500,000+ build floor and the founder is ready to commit a real timeline.

Hour 0–4: The Kickoff Call

A 60-minute working session with the founder and, where possible, the one or two operators who will use the system most. We don't run a slide deck. We run a structured conversation around five questions:

Question	What We're Listening For
What does success look like 90 days after launch?	Concrete outcome metric — orders processed, hours saved, errors reduced. If they can't name one, the project isn't ready to scope.
Walk us through the day this software changes.	The actual workflow, told as a story. This is where hidden requirements surface — manual reconciliations, paper handoffs, exceptions.
What system or process does this replace?	The current cost baseline — spreadsheets, a packaged tool, a manual process. Tells us the bar v1 has to clear.
What can this absolutely not do?	The non-negotiables, usually compliance, data residency, integrations, or performance. These shape the architecture before features.
What's the worst-case launch date?	The real timeline driver — investor demo, regulatory deadline, contract start. Drives the "Won't Have" column.

The other three hours of the first day are us writing up what we heard. Verbatim. We send it back to the founder before the day ends with a single ask: correct anything we got wrong before tomorrow morning. The founder fixing our notes is faster and more accurate than us guessing.

Hour 4–16: Async Research

By morning of day two we've already absorbed corrections. The next twelve hours are deep, async, and silent on the founder's side. Three workstreams run in parallel:

1. Competitive teardown. Whatever existing tools the founder mentioned — packaged ERPs, SaaS apps, internal scripts — we map their data models, user flows, and pricing. Not to copy, but to understand the founder's mental model. When they say "like Notion but for inventory," we need to know exactly which 30% of Notion they actually mean.

2. Integration and data inventory. Every external system the project touches — accounting software, payment gateways, GCash, BIR e-invoicing, Slack, Salesforce, third-party APIs — gets a row with its API maturity, auth model, rate limits, and known gotchas. This is where most cost overruns hide.

3. Risk register. Anything that could blow the timeline by more than two weeks goes on a list. PCI compliance? Real-time requirements? Unfamiliar regulatory regime? An integration with a government system that doesn't have a sandbox? We write each risk down with a mitigation and a cost-of-mitigation in engineering hours.

Hour 16–28: MoSCoW Triage

This is the highest-leverage block. We take every feature mentioned in the kickoff — typically 25 to 35 distinct items — and run MoSCoW prioritization: Must Have, Should Have, Could Have, and Won't Have (this round).

A typical wishlist breaks down something like this: 40% of the items are genuinely Must Have, 25% are Should Have, 25% are Could Have, and 10% are Won't Have. The percentages matter less than the discipline of forcing every feature into one of the four buckets.

The two columns founders care about most are usually wrong on first pass. The Must Have list is almost always too long — founders want to ship the version they imagined, not the version that's defensible to build. The Won't Have list is almost always too short — founders are reluctant to cut anything explicitly. We push hard on both. By the end of this block, the Must Have list typically loses three to five items and the Won't Have list typically gains five to eight.

The Won't Have column is the most valuable artifact in the entire sprint. It's the sentence we get clients to sign off on before we write a single line of code. "We are not building X, Y, and Z in this round" is what protects the engineering team — and the founder's budget — when scope creep tries to sneak in during week six of the build.

Hour 28–40: Estimate and Plan

With the Must Have list locked, estimating becomes mechanical. We've built enough Filipino-market custom software that we have confident hour ranges for most epic-level features: auth, role-based access, audit logs, payment integration, BIR-compliant invoicing, admin dashboards, dashboards-with-filters, file uploads with virus scanning, multi-tenant data isolation. Each Must Have feature gets an hour range — low, mid, high — based on integration complexity and edge cases.

We add infrastructure choices on top. Hosting (Vercel, Supabase, AWS), database, auth provider, payment processor, observability stack. Each one comes with an opinion and a cost — both engineering and recurring.

The output is a two-tier price quote: a fixed-fee number for the Must Have v1, and a time-and-materials range for any Should Have items the founder wants in scope before launch. We don't quote Could Have or Won't Have. Those are explicitly excluded from the price. The build numbers we quote start at ₱500,000 and run into the multi-million range — that floor is what makes free scoping economically sane on our side.

A timeline is the last piece. We map the Must Have epics into milestones — typically four to six — and pin a target date to each. We don't promise dates we don't believe in. If the founder's "worst-case launch date" from the kickoff is shorter than what the Must Have list supports, we say so before quoting and move items to Should Have until the math works.

Hour 40–48: Delivery

The final eight hours are write-up, walkthrough, and revision. The deliverable is a single document with five sections:

1. Outcome and success metrics. What v1 must do, in the founder's own language.
2. MoSCoW board. All four columns, with reasoning for each Won't Have.
3. Architecture sketch. Stack, integrations, data model at the entity level.
4. Milestone timeline. Four to six milestones, each with its own deliverable and date.
5. Two-tier price quote. Fixed-fee for Must Have, T&M ranges for negotiable Should Have items.

We walk the founder through it live, capture revisions in real time, and send a finalized version within hours of the call. If they sign, we start the build the following Monday. If they don't, they keep the document and we shake hands. The sprint is free either way — we don't invoice for scoping, we don't claw it back from a future engagement, and the founder owns the document. That's how we stay honest about scoping the project the way it should be scoped, not the way that maximizes the build engagement.

---

What We Don't Do

Just as important as what's in the sprint is what's deliberately left out. A few things we used to do and stopped:

• No Figma mockups. They take days, anchor the founder on a specific UI before scope is locked, and create the illusion of progress without resolving any of the real risks. We sketch user flows, not pixels.
• No detailed technical specs. Spec belongs in the build phase, after scope is signed. Writing endpoint-level specs for features that get cut is the single most common form of wasted discovery hours we've seen.
• No competitive analysis decks. We do the teardown internally for our own understanding. We don't deliver a 40-slide market analysis the founder didn't ask for.
• No "phase 2" pricing. The temptation to anchor a much bigger future engagement is real. We resist it because it muddies the v1 conversation. We quote v1, we ship v1, and we re-scope phase 2 when phase 2 is actually next.

---

The Five Hardest Conversations

Most of the value in a scoping sprint comes from a small number of difficult conversations that founders won't have with themselves. The ones we have to push on consistently:

1. "This Must Have is actually a Should Have." Auth providers like Auth0 or Supabase Auth are usually fine for v1. Custom SSO almost never is. Cutting it from Must Have can save four to six weeks.
2. "This integration adds two weeks per system." Founders underestimate integration cost by an order of magnitude. Every external system is a separate engineering project with its own failure modes.
3. "You don't need a mobile app yet." A responsive web app covers 80% of mobile use cases for internal tools and B2B SaaS. Native mobile is almost always v1.5, not v1.
4. "You don't need real-time." Founders ask for real-time because it sounds modern. Most flows work fine with a 30-second poll. Real-time triples the infrastructure cost.
5. "You're describing two products." When the user persona shifts mid-conversation — "and the admins also need to..." — that's usually a sign of two products glued together. We push for one in v1.

The willingness to have these conversations in 48 hours, in writing, before any code gets written, is most of what scoping is.

---

Frequently Asked Questions

How much does a scoping sprint cost?

Nothing. The 48-hour sprint is free for every qualified project. After a 30-minute consultation call where we confirm the project is a fit — typically a build value of ₱500,000 or more — we run the sprint on us. The founder owns the resulting scope document whether or not they engage us for the build. We can do this because the build engagements we sign are large enough that the scoping hours pay for themselves several times over, and because losing the occasional sprint to a founder who walks away is cheaper than charging fees that distort the conversation.

Why ₱500k as the floor?

Below ₱500,000 in build value, the math doesn't support what we put into a scope. A real 48-hour sprint is roughly 30 engineering and product hours of senior time, plus the consultation, plus the live walkthrough. On a ₱200k project that's most of the build budget; on a ₱1M+ project it's a rounding error. We'd rather decline small projects honestly than under-scope them and burn both sides.

What if 48 hours isn't enough?

It almost always is for a single-product v1. The exceptions are projects with heavy regulatory compliance (healthcare, financial services with custodial obligations) or multi-product platforms with several distinct user personas. In those cases we run a 5-day sprint instead, and we say so on the kickoff call before we start.

What do we actually walk away with?

A scope document that includes outcomes, success metrics, MoSCoW board, architecture sketch, four-to-six-milestone timeline, and a two-tier price quote. The document is yours — you can take it to other vendors, sit on it, or use it to justify the build internally. We don't lock the work behind an exclusive engagement.

How is this different from a "discovery phase"?

Traditional discovery phases run two to four weeks and produce a heavier artifact: detailed specs, full mockups, database schemas, sometimes prototypes. They cost ₱150,000–₱400,000 and they delay the build. Our 48-hour sprint produces a scope, not a spec — enough to commit to a build, not so much that we've burned weeks getting there. And we don't bill for it. Spec writing happens during the build, when it's cheapest and when the right calls are obvious from working code.

What if the founder isn't sure what they want?

That's the most common case, and it's exactly what the kickoff call is for. We don't expect founders to arrive with a finished feature list. We expect them to arrive with a problem and an outcome. Translating that into a feature list is our job, not theirs.

---

Key Takeaways

• Scope creep is the #1 cause of software project failure. 52% of failed projects fail because of it. A scoping sprint is the cheapest defense.
• Our scoping is free. It follows a 30-minute consultation call and produces a document the founder owns, build engagement or not.
• ₱500,000 is our build floor. Below that, the scoping math doesn't work and we'll say so honestly on the consultation call.
• 48 hours is enough for most v1 projects. Longer discovery phases produce heavier artifacts but rarely better decisions.
• The Won't Have column is the most valuable thing scoping produces. It's the sentence that protects the budget when scope creep tries to sneak back in.
• Don't write specs during scoping. Spec belongs in the build phase. Writing detailed specs for features that get cut is the most common form of wasted discovery time.
• Estimating is mechanical once scope is locked. The hard part is getting the founder to commit to one v1, not three overlapping ones.

If you're considering a ₱500k+ custom software build and want a scope you can budget against in two days — not two months, and not for a fee — book a free consultation call. We'll tell you on that call whether 48 hours is the right shape for your project, and if it is, we'll start the sprint.

---

Further reading on related decisions: How Much Does Custom Software Cost in the Philippines?, Off-the-Shelf ERP vs Custom-Built, and Why Philippine Startups Are Choosing Custom Software.