Primary Analytics: How a 7-Day Scoping Pass Saves Six Figures on Product Development

Why Fora Soft wrote this playbook

Since 2005 we have shipped 625+ software products. That means we have also sat through 625+ kickoff meetings where the founder says “we already know what we want, can you just start building?” Every time we agreed, something broke: estimates drifted, priorities changed after the UI was designed, a missed integration doubled the scope. Every time we insisted on a proper scoping pass first, the project shipped faster and cheaper.

We turned that lesson into a product: Primary Analytics. It is our 4–7 day, up-to-20-hour, completely free scoping phase. It is not a sales pitch with a PDF; it is an analyst-led working session that produces a priced, prioritised product outline the same week. If it turns out we are not the right partner, you still walk away with the plan.

This playbook explains why scoping phases matter, how Primary Analytics differs from full discovery (what we call Comprehensive Analytics), which deliverables you should insist on, and when to pick each option. It’s the honest version for product owners deciding whether to commit budget, not a brochure.

Why scoping matters — the data behind “measure twice, cut once”

Every statistic about software-project failure eventually points at the same root cause: building the wrong thing, or building the right thing in the wrong order, because nobody stopped to define the scope.

Translation: the cheapest mistake you will ever make is an hour in a scoping workshop. The most expensive is a pile of code solving the wrong problem.

What Primary Analytics actually is (and what it is not)

Primary Analytics is a focused, time-boxed pass: one business analyst, up to 20 hours of work spread over 4–7 calendar days, producing a structured document you can act on the same week. It is not a sales discovery call; it is real work delivered for free.

What you get

A one-page product summary in your own voice, a ranked feature list grouped as must-have / should-have / nice-to-have, a rough architecture sketch with technology recommendations, a directional time-and-cost estimate (±30% band), a red-flag list of the biggest risks, and a go/no-go recommendation that says whether we think Comprehensive Analytics is worth running next.

What it is not

Not a clickable prototype (that lives in Comprehensive Analytics). Not a 40-page Software Requirements Specification. Not a legally binding fixed-price SOW. Not a design deliverable. The point is speed and direction, not polish.

Who runs it

A senior business analyst with a second-pair-of-eyes check from a solution architect. Not a salesperson with a Google search. We only staff Primary Analytics with analysts who have shipped similar products before — the speed depends on pattern recognition.

Primary Analytics vs Comprehensive Analytics — the side-by-side

Both are scoping phases. They answer different questions and cost different amounts of time.

Primary Analytics is the scout; Comprehensive Analytics is the expedition. Most founders benefit from running Primary first to decide whether to commit to Comprehensive.

Discovery vs POC vs prototype vs MVP vs pilot — what each one answers

These words get used interchangeably. They should not be. Each answers a different question and costs a different amount.

1. Discovery / Scoping. Answers "what do we actually build?" Output: a plan, an estimate, a priority list. No code. Primary Analytics is the short version; Comprehensive Analytics is the long version.

2. Proof of Concept (POC). Answers "is this technically possible?" Output: a tiny code experiment run in a lab or notebook. No users. Usually a couple of weeks.

3. Prototype. Answers "does this feel right to a user?" Output: a low- or high-fidelity mockup, often clickable. Tested with a handful of real users. Weeks, not months.

4. Minimum Viable Product (MVP). Answers "will the market pay for this?" Output: a real product with the smallest viable feature set, launched to real users. Months. Needs billing, auth, analytics.

5. Pilot. Answers "does this work in the field at a limited scale?" Output: the MVP (or full product) running with a small set of real customers, usually in a single geography or segment. Precedes full launch.

The Primary Analytics process in four passes

We run Primary Analytics in four short passes, each mapped to a single day or two. The whole thing is built to fit around a founder’s schedule — we need roughly 3–4 hours of your time across the week.

Day 1 — Kickoff & context pull

45–60 minute call with the founder / product owner plus one stakeholder if available. Analyst captures the business goal, target user, commercial model, competition, and any hard constraints (deadline, budget cap, regulatory). We leave the call with enough to work independently for the rest of the week.

Day 2–3 — Feature synthesis & prioritisation

Analyst writes a clean feature list, groups by must-have / should-have / nice-to-have, maps them to high-level user stories, and flags cross-cutting concerns (auth, compliance, payments, offline-first, real-time, internationalisation). Architect reviews the list and proposes a stack.

Day 4–5 — Estimate & risk log

Senior developer (or two) sanity-check the scope and produce a directional estimate for the must-haves and a separate one for the should-haves. Analyst drafts the risk log: the three to five things most likely to blow up the plan.

Day 6–7 — Delivery & walkthrough

We send the document, schedule a 45–60 minute walkthrough, and leave you with a signed PDF plus a Notion or Google Doc version you can share with co-founders, investors, or other agencies. The document is yours regardless of whether you engage us for the build.

What a good scoping deliverable looks like

A scoping document is only useful if someone on your team can pick it up on Monday and start making decisions. Here is what we always include, and why.

1. One-page product summary. If your mother reads the first page, she should know what you are building and who it is for. Two paragraphs plus three bullets. If we cannot hit that, the problem is still fuzzy.

2. Prioritised feature list. Must / should / nice. Each item half a sentence. No epics yet. This is the most-used page in the document — founders print it out.

3. Directional estimate with a band, not a single number. Real work takes a range. “Must-haves: 14–20 weeks, at team rate X” beats a false-precision “17.3 weeks” every time.

4. Architecture sketch. One A4 diagram, four to seven boxes, with a recommended stack and the reason (e.g., React Native for mobile because your team is React). No 20-layer cake.

5. Top 3–5 risks. Named, not abstract. “Apple App Store subscription review can take 2 weeks if we use family sharing wrong” is a risk. “Technical risk” is not.

6. Go/no-go recommendation. Our honest view on whether to build, whether to run Comprehensive Analytics next, or whether to kill the idea. If we would not start, we say so — that is worth more than a yes.

Mini case — how Primary Analytics saved a founder from building the wrong thing

Situation. A founder came to us wanting to build a Zoom-style telemedicine platform from scratch. Budget ~$180K, timeline 6 months. He had already interviewed three doctors and two clinic managers.

Day 1–7. We ran Primary Analytics. The feature list was 40 items long; our prioritisation pass cut it to 11 must-haves. The architect recommended LiveKit instead of custom WebRTC, saving 8 engineer-weeks. The risk log flagged HIPAA BAA setup as a 3-week prerequisite the founder had not budgeted for. The directional estimate was $95K–$135K for the must-haves over 16–22 weeks, versus the founder’s $180K / 6-month plan.

Outcome. The founder raised less capital than he thought he needed, locked in the must-have scope, and skipped two features the doctor interviews had accidentally glorified. Similar compressions are normal when pattern recognition is applied early. Our portfolio of 625+ projects and named case studies like BrainCert ($10M ARR) and TradeCaster (46K users) started from the same kind of scoping pass. Want a similar assessment? Book a 30-minute scoping call.

Decision framework — Primary, Comprehensive, or skip

Q1. How concrete is the idea? If it fits on a napkin, Primary Analytics is enough to turn it into a plan. If it is already a PRD with 200 items, go straight to Comprehensive.

Q2. How soon do you need a number? This week: Primary. Two to four weeks: Comprehensive. Immediately: you are pattern-matching, not deciding, and no scoping phase will help.

Q3. How large is the build? Under $100K and under 4 months: Primary is usually sufficient. $100K–$500K with real integrations: run both (Primary to decide, Comprehensive to lock). Above $500K or regulated: always Comprehensive, often two rounds.

Q4. Are you raising? If you are showing investors, Comprehensive Analytics gives you the credible wireframe pack. Primary gives you the napkin-plus, which works at pre-seed but shows thin at seed+.

Q5. How confident is your team on the stack? Confident on stack, new to category: Primary is enough. Confident on category, new to stack: always go Comprehensive so the architect can de-risk the build.

Five pitfalls that wreck scoping phases

1. Letting sales set the estimate. A salesperson will commit to a timeline before the team has seen the scope. Push back — ask for the estimate to come from engineers and the analyst, signed off by the architect. Sales-driven estimates are the #1 cause of fixed-price death marches.

2. Running discovery without a time box. Without a deadline, analysis paralysis sets in. Four weeks becomes 12; the team loses momentum; nobody wants to commit. Always box your discovery: Primary = 7 days, Comprehensive = 4 weeks max.

3. Skipping the user. Discovery sessions where the only voice is the founder miss half the signal. Insist the analyst runs 3–5 user interviews even in the 7-day pass. Skipping them turns the scoping document into an echo chamber.

4. Accepting single-point estimates. A number with no range is a promise the vendor cannot keep. Always ask for a band and the assumptions behind the lower and upper bound. Estimates that collapse to a single point are hiding risk.

5. Treating the document as a contract. Primary Analytics is directional. It is not a fixed-price SOW. Treating it as one is how projects hit 200% overruns. The SOW lives after Comprehensive Analytics, with all the risks priced in.

Concrete benefits — what Primary Analytics returns on zero invoice

1. A priced, ranked plan in 4–7 days. Everything else in this list follows from that: fundraising conversations, agency comparison, internal budget approvals.

2. Faster time to market. Forrester found design-thinking-led projects ship 85% faster. Primary Analytics is a lightweight version of the same discipline — even a week of structured thinking compresses the build by weeks later on.

3. Better cost control downstream. Projects with proper scoping hit ±15% estimate accuracy; projects without scoping blow out 200–300%. Our cost-cutting guide covers the techniques we apply once Primary Analytics is done.

4. Less scope creep. With a ranked feature list in hand, the "oh and also..." requests get graded against the priority grid. Our data suggests 60% fewer change requests on projects that pass through scoping first.

5. Relationship signal. You see how our analysts think, how fast we turn things around, and whether our communication style fits yours — before any money changes hands. Most clients who become long-term partners say the Primary Analytics week was the deciding signal.

When Primary Analytics is not the right step

Primary Analytics is for early-stage decisions. It is not for projects already mid-flight, not for regulatory-heavy rewrites, and not for fixed-price contracts that need board approval next Monday.

Skip straight to Comprehensive Analytics when your project is regulated (HIPAA, PCI, GDPR with biometrics), when you are doing a multi-million dollar rewrite, when you need clickable prototypes for a fundraising pitch, or when your investors have already committed on the premise of a detailed scope. In all of these, the ±30% band is too loose.

KPIs to track during and after scoping

Quality KPIs. Feature-list alignment score (founder agrees with the priority grid inside the walkthrough call: target 90%+). Number of show-stopper risks identified (healthy range: 3–5). Estimate band tightness (Primary: ±30%; Comprehensive: ±15%).

Business KPIs. Time from kickoff to go/no-go decision (target: 7 days for Primary, 21 days for Comprehensive). Reduction in must-have feature count after prioritisation (typical: 30–50% off the original list). Discovery spend as % of final project spend (healthy: 5–15%).

Reliability KPIs. Post-build estimate accuracy (the final invoice vs. Comprehensive Analytics estimate: target <15% drift). Scope-change rate after sign-off (target: <5 material changes in the first quarter). Founder satisfaction (NPS on the walkthrough: target 50+).

FAQ

What to Read Next

Ready to swap uncertainty for a plan?

Primary Analytics is the cheapest de-risking step you can take on any software project. Seven days, 20 analyst hours, zero invoice. In return you get a priced, ranked plan, a risk log, and a go/no-go recommendation you can walk into the next fundraising meeting with. For most founders, it also saves six figures in scope creep and wrong-direction engineering.

We have run this playbook on 625+ projects since 2005. We are not fast because we cut corners — we are fast because we have seen the same patterns a few hundred times and know which ones reward pattern matching and which ones need a deeper pass. If you want the document on your desk by next Monday, the kickoff call is 30 minutes from now.