Our process · Chicago
How we run software projects from discovery to launch
Software projects go wrong in predictable places: unclear requirements, an architecture nobody agreed on, and a launch with no plan for what happens after. Our process is built around closing those gaps early. Here is what working with LaunchPad Lab actually looks like, phase by phase, including what we need from you at each step.
What you are walking into
LaunchPad Lab is an IT company specializing in web, mobile, software development, and AI solutions. Most of our work is custom product work for US businesses that need a partner from scoping through production support.
Web
Full-stack web applications, dashboards, customer portals, and the APIs underneath them.
Mobile & Software
Cross-platform mobile apps and internal software built to fit a workflow you already run on.
AI solutions
LLM-backed features and data pipelines added where they remove real manual work.
Product discovery: defining the problem before the solution
Discovery typically runs two to four weeks. We interview users and stakeholders, map the current workflow, and write down what the product must do in its first release. The output is a scoped MVP, a technical architecture, and a delivery plan with estimates. Just as important is what we cut. A first release that proves the core idea beats a broader one that ships late, and the cut list from discovery becomes your roadmap for the next phase.
You do not need a finished specification to start. Part of discovery is turning the notes you already have into something engineers can estimate against, so the first sprint does not begin with guesses.
What discovery produces
A scoped MVP, a written architecture, and a delivery plan with estimates you can plan a budget around.
- User and stakeholder interviews with the people who run the workflow today
- A written list of what the first release must do, and what waits
- Estimates per workstream, so sequencing is a decision rather than a surprise
Technical architecture and stack decisions
Architecture decisions get made in discovery, not during the first sprint. That covers the data model, API design, hosting, authentication, and the framework choice. Each choice gets written down with its tradeoffs, so future engineers understand why.
Node.js
Real-time and full-stack JavaScript systems
One language across client and server, with a large hiring pool to hand off to.
Python
AI features and data pipelines
The usual choice when model work or scheduled data processing sits inside the product.
Django
Structured business applications
Good fit for permission-heavy internal tools with a predictable data model.
Laravel
Business applications with a familiar PHP base
Useful when your team already maintains PHP and wants to keep it that way.
Rails
Fast product builds
Strong fit when the priority is reaching a working release quickly.
We favor stacks with long support windows and available talent. Choosing one nobody can hire for is how a product becomes expensive to maintain three years later.
A written tradeoff record keeps the decision reviewable. If the reasoning no longer holds, you can see what changed and what it costs to move.
Architecture decided late is a rewrite with a deadline attached
The data model, the API shape, and the hosting story are cheaper to argue about on a whiteboard than in a codebase three sprints deep. Discovery is where we settle them, in writing, with the tradeoffs named.
Agile delivery in two-week sprints
Once discovery closes, we work in two-week sprints. Each one ends with working software in a staging environment, not a status report. You see progress as it happens and can redirect between sprints rather than at a milestone review.
Scope changes get estimated and scheduled into a sprint. They do not get absorbed quietly and surface later as a slipped date.
Between sprints
A short review of what shipped, what moved, and what you want changed before the next sprint begins. Redirecting here costs a conversation. Redirecting later costs a sprint.
- Sprint planning The two weeks get a written goal and a short list of work that fits it.
- Staging build Working software you can open and click through by the end of the sprint.
- Review You walk the build with the team and say what should change.
- Re-estimate New requests get sized against what is already committed, before they enter a sprint.
Design and prototyping alongside engineering
Product design runs in parallel with engineering from the first sprint. Figma prototypes get tested with real users before the feature is built, which is cheaper than rebuilding it after.
For teams without a designer, we cover the interface work. For teams with one, we plug into their process. Either way, the goal is that what gets built matches what users actually understood from the prototype.
No in-house designer
We own the screens end to end, from first wireframe to the states engineers build against.
In-house designer
We work inside your files and review rhythm so your team keeps the design system.
Testing, QA, and release management
Testing is part of each sprint, not a phase at the end. That includes automated tests for the core logic, manual review of new features, and load checks before anything customer-facing goes live.
Releases move through staging into production with rollback plans. If a launch has a fixed date, we work backward from it and say early when the date and the scope do not both fit.
Automated
Tests on the core logic run with every change, so a working feature stays working.
Manual review
New screens and flows get walked by a person before they reach your users.
Load checks
Traffic the feature was not built for gets tested before launch day, not after.
Rollback plan
Every release has a way back to the last good version before it goes out.
Launch and the first weeks in production
Launch day is mostly logistics: deployment, monitoring, and a support channel for the first users. The weeks after matter more. Real usage surfaces the cases nobody predicted, and having the same engineering team on hand shortens the time between a reported problem and a fix.
We watch error rates, performance, and the specific metrics the feature was built to move.
Handoff or ongoing support
Some clients take the codebase in-house after launch. Others keep us on for support and continued development. For handoff, we write documentation, walk your engineers through the architecture, and stay available for questions during the transition.
Taking it in-house
Written documentation, a walkthrough of the architecture with your engineers, and a window where questions get answered while your team takes over deployment.
Staying with us
Support and continued development on the same team that built it, with the same sprint rhythm.
There is no penalty either way, and the decision usually depends on whether you have engineers to absorb the work rather than on anything in the contract.
What we need from you
Most delays trace back to a decision nobody could make. These three things keep a project moving, and none of them require a technical background.
- One decision-maker Someone who can approve scope without a second meeting. It does not have to be the founder. It has to be the person who can say yes to a cut list.
- Access to the workflow Time with the people who run the process today, not just the people who bought it. An hour with the team doing the work saves a week of guessing at requirements.
- Realistic timelines A weekly product owner moves fastest. Batched feedback slows every sprint behind it. If your dates are fixed by a board or a season, say so in discovery and we plan backward from them.
You do not need a finished specification. That is what discovery is for.
Ready to start with discovery
Bring the problem, the workflow, and whatever notes you have. We will tell you what discovery would cover for your case, what it produces, and what it costs before anything starts.
Where we work from
LaunchPad Lab
448 N La Salle Dr Fl 9, Chicago, IL 60654, United StatesMonday–Friday, 9:00 AM – 6:00 PM
Prefer to start with a form? Use the contact page and we will reply within one business day.