March 28, 2026 | 8 min read
The 72-Hour Window
There is a moment in every small team where an idea clicks. Not a vague "we should build something" idea, but a specific problem with a specific audience and a clear way to solve it. When that moment hits, you have a narrow window of energy and clarity. If you do not act on it fast, the idea fades into a note on your phone that you never look at again.
We have learned to ride that wave. At Obsidian Clad Labs, we have shipped products that went from a Friday night conversation to a live, deployed SaaS application with pricing plans and payment processing by Monday morning. Not a landing page. Not a waitlist. A working product that people could sign up for and use.
Here is the playbook we follow when we do a 72-hour sprint. It is not about cutting corners. It is about knowing which corners do not exist yet and should not be built until you know someone wants to pay for this thing.
Step 1: Start with the Landing Page
This sounds backwards. Most developers want to build the backend first, get the data model right, set up the database. We used to do that too. Now we start with the landing page, and it is the single biggest change to how we ship.
The landing page forces you to answer the hardest question: what does this product actually do, and why should someone care? You have to write the headline, the feature descriptions, the pricing tiers, and the call to action. You have to articulate the value proposition in plain language that a stranger can understand in five seconds.
If you cannot write a compelling landing page, the product idea is not clear enough yet. Go back and refine it. But if the landing page practically writes itself, you know you have something. We aim to have the landing page done within the first four to six hours. That includes the hero section, three to four feature blocks, pricing cards, and a footer. Ugly is fine. Words matter more than design at this stage.
Step 2: Build the Core Feature Only
Every product has one core feature. The thing that solves the actual problem. For a grading tool, it is the grading engine. For an image editor, it is the image processing pipeline. For a contract analyzer, it is the analysis endpoint. Everything else -- user settings, admin dashboards, notification preferences, profile pictures -- is decoration that can wait.
In a 72-hour sprint, you build the core feature and a minimal wrapper around it: user registration, login, a page where they can use the feature, and the feature itself. That is it. No settings page. No admin panel. No onboarding tutorial. No analytics dashboard.
This is the hardest discipline for developers because we love building things. Every hour you spend on a nice-to-have is an hour not spent on the thing that will determine whether anyone uses this product. Save the polish for version two, when you know version one is worth polishing.
Step 3: Use Your Existing Stack
A 72-hour sprint is not the time to learn a new framework. It is not the time to try that new database you read about. It is not the time to experiment with a different hosting platform. Use whatever you have shipped with before. The goal is speed, and speed comes from familiarity.
For us, that means FastAPI for the backend, Next.js for the frontend, PostgreSQL for the database, Railway for backend hosting, and Vercel for frontend hosting. We can set up a new project on this stack in under an hour because we have done it a dozen times. The boilerplate is muscle memory. The deployment pipeline is automatic. We are writing application code within the first hour, not configuring build tools.
If you do not have an established stack yet, pick one and stick with it for at least three projects before you evaluate alternatives. The familiarity compounds. By the third project, you will be shocked at how fast you move.
Step 4: Deploy on Day One
This is non-negotiable. Within the first few hours, the site should be live on the internet. Not finished. Not polished. But live. A real URL that loads a real page, even if that page is just the landing page with a "coming soon" label on the sign-up button.
Deploying early does two things. First, it catches infrastructure problems immediately. DNS issues, SSL problems, build failures, environment variable misconfigurations -- you want to find these on Friday night, not Sunday night when you are trying to launch. Second, it creates momentum. Seeing your work live on a real domain, accessible to the world, changes the energy of the sprint from theoretical to real.
We push to deploy after every major feature addition. Continuous deployment is not just a best practice, it is a sanity check. If your latest change breaks the build, you know immediately. If it works, it is live for anyone to see. There is no "big bang" launch moment where everything needs to work at once.
Step 5: Ship Ugly, Polish Later
The first version of every product we ship looks rough. The spacing is off. The colors are not quite right. The error messages are developer-facing instead of user-facing. The loading states are either missing or just the word "Loading..." in plain text.
And that is fine. Nobody is evaluating your CSS on day one. They are evaluating whether the product solves their problem. A beautifully designed tool that does not work is worth less than an ugly tool that does. You can always make it pretty later. You cannot always recapture the momentum of a fast launch.
The exception is your landing page. That should look decent because it is the first thing a potential user sees. But the app itself? Ship it functional. Ship it correct. Ship it stable. Pretty comes in week two.
What We Do Not Build in 72 Hours
Just as important as what we build is what we deliberately skip.
No admin panel. We use direct database queries for the first few weeks. No analytics beyond what our hosting platforms provide for free. No email sequences or drip campaigns. No user onboarding wizard. No forgot-password flow (we add this in week one, but not during the sprint). No mobile-responsive polish (basic responsiveness from Tailwind is enough). No unit tests during the sprint (controversial, but we add them in week one when we know what we are actually keeping).
Everything on this list is important. None of it is important in the first 72 hours. Your only goal in those 72 hours is to get the product live and usable so that you can start learning from real users. Everything else is optimizing for a future that may not happen.
The Mindset That Makes It Work
The 72-hour sprint is not really about speed. It is about ruthless prioritization. It is about saying "no" to every idea that is not the core feature. It is about accepting that the first version will be embarrassing and shipping it anyway. It is about trusting that you can fix things next week, because next week the product will exist and you will have real feedback to guide your decisions.
The biggest risk for a small team is not shipping a bad product. It is not shipping anything at all. Spending months perfecting something in private, only to discover that nobody wants it. The 72-hour sprint eliminates that risk by getting you to market fast enough that the feedback loop starts before your enthusiasm fades.
We have done this multiple times now. Not every product becomes a hit. But every product launches, and we learn something from each one. The ones that get traction, we invest in. The ones that do not, we learned cheaply. That is the playbook. And it starts with deciding to ship.
Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.
tags: saas, startup, webdev, beginners
Originally published at TeachShield Blog
Top comments (0)