The Situation
Ourz came to Halcrow at the earliest stage of product development: a founding team with a clear problem statement, a target market, and no software. The ask was to build a first version of a SaaS product — an MVP that could be put in front of early customers to validate whether the product direction was right.
The specifics of Ourz's market and product are not published here at the client's request. What's relevant for this case study is the structural challenge that all early-stage SaaS builds share: the product you think you need pre-launch rarely matches the product you need post-launch.
Why they called us
First-time SaaS founders typically approach build the same way they approach other projects: define requirements, get a quote, build to spec. This model fails for early-stage SaaS because the requirements document assumes certainty that doesn't exist.
What happens: the agency builds to spec. The founders launch. The first real users have completely different needs than the spec anticipated. The product is rebuilt. Months and significant cost are lost.
The alternative: Build the smallest thing that allows you to learn what users actually need, put it in front of real users, and iterate from real feedback. This is not a philosophical preference — it's the empirically fastest path to a product that works.
How we worked
Phase 1: MVP Scope Definition
Before writing a line of code, we worked with the Ourz team to reduce the feature scope to the essential: what is the minimum capability that proves the core value proposition to a customer? Not a list of features the product should eventually have. The one thing that, if it works, validates the rest.
This was a difficult conversation because founders want to build everything. Halcrow's role was to hold the scope boundary — not because features are bad, but because unbounded scope kills early-stage products through delayed launch.
Phase 2: Build
MVP built to the reduced scope. Core user flows only. No admin dashboard. No billing integration. No onboarding flow. The things that matter to first users: does the core product work?
Phase 3: First Users
The Ourz team put the MVP in front of their first target users. Real feedback came in within weeks of launch. Several assumptions baked into the original product direction were wrong. Several others were validated.
Phase 4: Iteration
The feedback cycle from Phase 3 drove the feature decisions for Phase 4. We built what users needed, not what the spec anticipated. The product that emerged from six months of build-and-iterate was materially different from the product the spec would have produced.
WHAT CHANGED
Ourz had a functional SaaS product with paying early customers by the end of the engagement. The specific metrics aren't published here, but the structural outcome is:
- MVP launched faster than a spec-to-build model would have produced
- Product direction validated by real users before significant additional investment
- Feature set driven by actual customer needs, not founder assumptions
WHY THIS WORKED
The embedded proximity model — Halcrow inside the Ourz team, not servicing a spec — meant we could adapt to feedback in real time rather than waiting for formal change requests.
