Your First Engineering Sprint: What to Build

Answer capsule: Your first engineering sprint should contain exactly one thing: the shortest possible path to a working version of your riskiest assumption. Scope it to what a real user can touch in two weeks. No auth flows, no dashboards, no admin panels. Build the feature that proves your core value proposition exists, and nothing else.

This post is for SaaS founders who have started, or are about to start, working with an engineering team. Whether that's a co-founder, a contractor, or a small hired squad. If you're pre-product and trying to figure out what goes into that very first two-week window, this is written for you specifically, not for seed-stage teams already refining an existing roadmap.

The first engineering sprint is the most consequential two weeks in your product's life. Not because what you build will survive contact with users (it probably won't), but because the decisions you make about scope in that window reveal exactly how clearly you understand your own problem. Founders who scope Sprint 1 well tend to ship faster, pivot cheaper, and avoid the expensive regret of building authentication systems before anyone has confirmed they want to log in to anything.

And yet most first-time SaaS founders blow it. Not from laziness. From enthusiasm. They have a clear vision, a persuasive deck, and a backlog that reads like a Series A pitch. Then they hand that backlog to an engineer and wonder why, six weeks later, they still have nothing a real user can touch.

Here's how to do it differently.

The Problem With Just "Building the Product"

So what do founders actually mean when they say they want to build the product? Usually, they mean the version they imagined. That version has polished UI, a full user authentication flow, role-based permissions, a billing integration, and probably an analytics dashboard. It feels like the minimum because they've been living with the idea for months. Familiarity reads as simplicity. It isn't.

Engineers can spot this problem immediately. A typical SaaS authentication system, built properly with password resets, email verification, and OAuth, takes three to five days of engineering time before a single line of actual product code gets written. Add Stripe integration and you're looking at another two to four days depending on your subscription model. You've now spent your entire first sprint on infrastructure that tells you exactly nothing about whether your product hypothesis is correct.

That math never works.

And honestly? This isn't an abstract concern. Baremetrics, the subscription analytics company, famously launched with a product so narrow it only showed MRR and churn pulled from Stripe. That was it. No custom reports, no team features, no integrations beyond the one thing they needed to prove. Their first sprint probably looked nothing like their eventual product. That gap between "what we launched" and "what we'd imagined" is exactly where real validation lives.

I keep thinking about that gap. Most founders treat it as a failure of ambition. It's actually a sign of discipline.

Start With Your Riskiest Assumption, Not Your Best Feature

Every SaaS product rests on a set of assumptions. Some are safe, some are dangerous. Your first sprint should attack the most dangerous one.

A riskiest assumption isn't the feature you're most excited about. It's the belief that, if wrong, makes everything else irrelevant. For a scheduling SaaS targeting healthcare practices, the riskiest assumption might be that office managers will actually adopt a new tool rather than defaulting to phone calls. For a data pipeline product aimed at e-commerce operators, it might be whether their Shopify data is clean enough to generate meaningful outputs. Different problem, same principle.

You find your riskiest assumption by asking: what has to be true for this business to work, that I cannot confirm without building something? Everything that doesn't touch that question belongs outside Sprint 1.

Practically, this means writing your riskiest assumption on a whiteboard before you write a single ticket. Then look at your proposed sprint scope and cross off anything that doesn't directly test it. You'll probably cross off more than half the list. Not always, but often. This discipline is what separates founders who understand their own problem from those who are just building features because building feels like progress.

My advice? If you're struggling to identify your riskiest assumption in the first place, running a focused discovery sprint with your development partner can help clarify exactly what needs to be tested before a single line of code gets written.

What Actually Belongs in Sprint 1

A well-scoped first sprint for a SaaS product usually contains three to five things. Let's be real about what that means.

The core action. Whatever the user does to get value, that interaction needs to work. If you're building a document summarisation tool, the user needs to be able to paste text and receive a summary. Everything else is scaffolding around that moment. Just that moment.

Enough UI to make it usable. Not beautiful. Not branded. Functional. You need a user to complete the core action without needing you in the room to explain what to do. This can be an unstyled form, a command-line wrapper dressed up as a web page, or a Retool interface. The bar is "usable," not "presentable." That's a lower bar than most founders expect.

A way to observe what happens. This could be as simple as console logs you can read, a Notion database that captures outputs, or a basic logging setup. You need to see what users are doing and whether the output is correct. Google Analytics is optional. Knowing whether your core feature produced a useful result is not. Those are very different things.

Hardcoded data where possible. If your product eventually needs dynamic user data, consider whether Sprint 1 can use hardcoded or seeded data instead. This removes an entire layer of complexity, an API integration or a database schema, that isn't actually testing your riskiest assumption. Dropbox's original demo video showed a product that didn't fully exist yet. The hardcoded approach is the legitimate engineering version of that same instinct, and teams at early-stage companies use it aggressively.

What doesn't belong: user authentication (unless auth is literally your product), payment flows, admin controls, email notifications, mobile responsiveness, or any feature described with the word "also."

Especially that last one.

Translating This Into Tickets Your Engineer Can Actually Use

Once you know what belongs in Sprint 1, you need to write it in a way an engineer can act on. Founders often write tickets as features: "Build the summarisation page." Engineers need acceptance criteria. They need to know what done looks like.

A better ticket format for Sprint 1 looks like this:

User can paste a block of text up to 2,000 words into an input field and receive a summary of three to five bullet points within ten seconds. Output is displayed on the same page. No loading spinner required. No saving of results.

Notice what that ticket excludes. Every exclusion is a decision that saves engineering hours and keeps the sprint on target. This is where clear product requirements documentation matters most, not to create busy work, but to establish what success actually means before anyone writes a line of code.

If you're working with a contractor charging between $120 and $180 per hour (a reasonable range for senior SaaS-focused contractors in 2026), a two-week sprint at four to five hours per day represents roughly $5,000 to $9,000 of spend. That's real money. Writing a ticket like the one above means that money is testing something specific. Writing a vague ticket means it's buying uncertainty.

And you know how that goes.

The Scope Negotiation You're Going to Have

Almost every first sprint involves a version of this conversation: your engineer suggests adding something that sounds reasonable, and you have to decide whether to include it. These conversations feel collaborative. They can quietly destroy your sprint scope.

"Should we just add basic auth so we can share it with users?" This is the most common one. It sounds safe. It's not. Adding auth mid-sprint shifts priority from the core feature to the scaffolding around it. The answer is almost always no. Use a shared password or a secret URL for now. Auth can wait until Sprint 2. That delay costs nothing important.

"Should we handle edge cases in the input?" Depends. If the edge case breaks the core function, yes. If it just produces a weird output you'll learn from, no. Let it break. That's data.

"Should we build this in a way that scales?" For Sprint 1, no. Build it to work. Build it to be replaceable. Scalability is a Sprint 6 problem. Personally, I think the number of SaaS products that have died waiting to be scalable before launch is far larger than the number that died from scaling too fast. Most teams never get to the scaling problem. They stall out earlier.

These aren't easy conversations. Engineers are trained to build things correctly. You're asking them to build things fast and incomplete on purpose. That requires trust and a clear explanation of why. The explanation is simple: we don't know if this is the right thing to build yet. Let's find out before we build it well. This challenge is common enough that many founders struggle with scope across their first build, regardless of industry. The principles apply across the board.

After the Sprint: What Each Outcome Actually Means

So the sprint ends. Now what? At the end of Sprint 1, you have three possible outcomes, and each one tells you something different. None of them is a failure. Only one of them is expensive, and it's the one that happens when you skip this sprint entirely.

The core feature works and users respond positively. Sprint 2 can add depth: better UI, a second feature, maybe auth. You've confirmed the riskiest assumption. Good. Move.

The core feature works but users don't engage. The engineering was fine. The hypothesis was wrong. You pivot the hypothesis, not the codebase. This is the cheapest version of this lesson you will ever receive. And honestly? This outcome is more valuable than the first one in some ways, because you found out early.

The core feature doesn't work technically. Something in the integration, the model, or the data pipeline failed. You've found an engineering problem early, before you've built seven features on top of a broken foundation.

Also cheap.

My take? Your first engineering sprint is not about building software. It's about running an experiment with code. The discipline required to scope it that way is harder than it sounds, especially when you have a vision you believe in deeply. But the founders who learn to treat early sprints as experiments rather than deliverables build faster, waste less, and ship things people actually want to use.

That's the whole point.