How We Build Software: Inside Our Dev Process
Every software agency says the same things on their website. Agile methodology. Cross-functional teams. Iterative development. Transparent communication. It all sounds good. None of it tells you what actually happens after you sign the contract.
I’ve been on both sides of this. I led engineering teams at Orb and Asana, where I hired and managed external development partners. Now I run Scott Street, where we are the external development partner. I’ve seen how the best agencies operate and how the worst ones burn through your budget while delivering code that your team will eventually rewrite.
The difference between a great software development process and a bad one isn’t which methodology you follow. It’s whether the team doing the work understands your business well enough to make good decisions when requirements are ambiguous, timelines are tight, and trade-offs need to happen fast.
This is how we actually build software. Not the marketing version. The real version, including the parts that are messy, the decisions that are hard, and the reasons we do things the way we do.
Why Most Software Development Process Content Is Useless
Search for “software development process” and you’ll find dozens of articles describing the same theoretical frameworks: Waterfall, Agile, Scrum, Kanban, SAFe. They’ll walk you through phases like “requirements gathering” and “design” and “testing” as if building software is a linear assembly line.
It’s not. Those frameworks are useful scaffolding, but they don’t tell you how a specific team actually works. They’re like describing cooking as “prep, cook, plate” — technically accurate, completely unhelpful if you want to know whether a chef can actually make a good meal.
What matters is the specific decisions a team makes: How do they figure out what to build? How do they handle it when the requirements change mid-project (they always do)? How do they decide what to ship first? What happens when something breaks after launch?
Those are the questions that determine whether your project succeeds or becomes a $100,000 lesson in what to avoid next time.
Phase 1: Discovery (1-2 Weeks)
Every project starts with understanding the problem. Not the solution you think you want. The actual problem that’s costing your business time, money, or opportunity.
This is the phase most agencies rush through because it doesn’t feel productive. Nobody’s writing code yet. There are no screens to review. But discovery is where the highest-leverage decisions get made. Getting it wrong here means building the right software for the wrong problem, or the wrong software entirely.
What Discovery Actually Looks Like
We start with conversations, not requirements documents. We want to understand how your business actually operates, not how you think it should operate on paper. That means talking to the people who do the work every day, not just the executive who’s sponsoring the project.
For Fox River Associates, discovery meant sitting with the person who processed AP invoices manually. We learned that the problem wasn’t just “we need to automate invoice processing.” The real problem was that their inventory reconciliation depended on invoice data being entered accurately and quickly, and the manual process introduced both delays and errors that cascaded through the entire supply chain.
For Mathnasium, discovery meant understanding that the franchise reporting problem wasn’t about dashboards. It was about franchise owners needing to compare student performance metrics across locations in a format that didn’t require an hour of spreadsheet manipulation every week.
Discovery produces three things:
A problem statement that everyone agrees on. Not “build us an app” but “reduce AP processing time from 40 hours to 4 hours per week while maintaining 99%+ accuracy.”
A scope map that identifies what’s in the first version and what comes later. The most common project failure mode is trying to build everything at once. Defining what’s out of scope is more important than defining what’s in scope.
A rough architecture that validates the approach is technically feasible. We identify risks early. If the project depends on an API that doesn’t exist or a data source that’s unreliable, we’d rather know now than three months in.
Phase 2: Design and Planning (1-2 Weeks)
Design isn’t just what the software looks like. It’s how it works, how data flows through it, and how users interact with it to accomplish their goals.
We design the core workflows first, then build the interface around them. This is the opposite of how most agencies work. They start with mockups and then figure out the logic underneath. That produces software that looks polished in a demo and falls apart in real use because the underlying data model doesn’t support the actual workflow.
Decisions That Shape Everything
The design phase is where we make the structural decisions that are expensive to change later:
Technology stack. We pick the tools that fit the problem, not the tools we’re most comfortable with. A simple CRUD application doesn’t need a microservices architecture. A high-throughput data pipeline doesn’t belong in a monolith. We’re opinionated, but pragmatic.
Integration architecture. Most custom software needs to work with your existing tools. How it connects to your CRM, your accounting system, your ERP, or your communication tools determines half the project’s complexity. We map every integration point and prototype the riskiest ones before committing to the full build. If you’re dealing with disconnected systems, this is the same challenge we address in our API integration work.
Data model. The shape of your data determines what your software can and can’t do. A CRM built around “contacts and deals” works differently than one built around “relationships and engagements.” We spend time getting the data model right because changing it later means changing everything that depends on it.
By the end of this phase, you have wireframes for the core screens, a technical architecture document, and a project plan with two-week milestones. You know what you’re getting, when you’re getting it, and what it costs.
Phase 3: Build (4-12 Weeks)
This is where the code gets written. Our development process follows two-week sprint cycles, but the specific rhythm matters less than the principles underneath it.
How We Actually Write Code in 2026
The software development process has changed more in the past two years than in the previous decade. 85% of professional developers now use AI coding assistants daily, up from 18% in 2023. We use them too. But using AI well in development is different from using it at all.
AI tools are excellent at generating boilerplate, writing tests, catching bugs, and handling repetitive implementation work. They’re poor at understanding business context, making architectural trade-offs, and deciding what to build in the first place. We use AI to amplify our engineers, not to replace the judgment that comes from years of building production systems.
In practice, this means our developers spend less time writing routine code and more time on the things that actually determine project success: understanding requirements, designing systems, reviewing output, and making the trade-off decisions that no tool can automate.
The result is faster delivery without sacrificing quality. A project that would have taken 16 weeks three years ago now takes 10-12, not because we’re cutting corners, but because the implementation phase has genuinely compressed while the thinking phases stay the same length.
Two-Week Cycles With Real Demos
Every two weeks, we deploy working software to a staging environment and walk you through what’s new. These aren’t slide deck updates. You’re clicking through real screens with real data.
This matters for two reasons. First, seeing working software reveals misunderstandings that documents can’t. You might tell us the approval workflow has three steps, but when you see it running, you realize there’s a fourth step that only happens for orders over $50,000. Catching that in week four is a minor adjustment. Catching it in week twelve is a rewrite.
Second, it keeps the project honest. If something is behind schedule, you’ll see it in the demo — not in a status report that uses words like “tracking to plan” while the codebase tells a different story.
How We Handle Change Requests
Requirements change. Always. A new business scenario comes up, someone realizes a workflow is more complex than originally described, or priorities shift because the business environment changes.
We don’t treat change requests as scope creep to be punished with change order fees. We treat them as new information. The question isn’t whether to accommodate them — it’s how to accommodate them without derailing the project.
Our approach: if the change is small, we absorb it in the current sprint. If it’s significant, we discuss the trade-off. Adding a new feature usually means pushing something else to a later phase. We’ll explain the options and let you decide. This is the same principle that makes our process work for companies at any scale — every decision is transparent, and nothing happens without your buy-in.
Phase 4: Testing and QA (Ongoing + 1-2 Weeks Dedicated)
Testing isn’t a phase at the end. It happens throughout the build.
Every feature gets automated tests as it’s built. We run the full test suite on every code change. We test on the devices and browsers your users actually use, not just the latest Chrome on a MacBook.
But automated testing only catches the bugs you think to test for. The dedicated QA period at the end is about finding the bugs you didn’t anticipate. Edge cases. Weird data combinations. The thing that happens when a user clicks a button twice rapidly or submits a form with unexpected characters.
We also run security testing on every project. SQL injection, cross-site scripting, authentication bypass, data exposure — the OWASP Top 10 is the baseline, not the ceiling. For regulated industries like healthcare, there are additional compliance requirements. Our HIPAA-compliant software guide covers what healthcare projects specifically require.
Phase 5: Launch (1 Week)
Launch is not the end. It’s the beginning of the software’s actual life.
We deploy to production using infrastructure that matches the project’s requirements. A low-traffic internal tool doesn’t need the same infrastructure as a customer-facing application handling thousands of concurrent users.
Every launch follows the same checklist:
- Monitoring and alerting configured before the first user touches the system
- Database backups running and verified
- Error tracking capturing exceptions with full context
- Performance baselines established so we can spot degradation
- Rollback plan documented and tested in case something goes wrong
The first week after launch is the highest-touch period. We monitor everything, respond to issues immediately, and make the small adjustments that always surface when real users interact with real software in real conditions.
Phase 6: Support and Iteration (Ongoing)
Software isn’t a building. It’s a garden. It needs ongoing attention, maintenance, and occasional renovation.
After launch, most of our clients move to a retainer model. This covers security updates, performance monitoring, bug fixes, and incremental improvements. The first 30 days after launch surface the most valuable feedback, because real usage patterns always differ from assumptions.
We typically see three types of post-launch work:
Quick fixes — things that technically work but frustrate users. A button in the wrong place, a workflow that requires one too many clicks, a report that’s missing a column.
Optimization — the system works but could work better. Database queries that slow down as data grows. Features that users access differently than expected. Integrations that need to handle higher volume.
New features — the original scope solved the original problem, and now the business is ready to tackle the next one. This is where having a team that already understands your business pays off. There’s no ramp-up time, no re-explaining your data model, no re-learning your workflows.
What to Look for in Any Development Team’s Process
Whether you work with us or someone else, here’s how to evaluate a software development team’s process. These are the signals that separate teams who deliver from teams who don’t.
Green Flags
They ask more questions than they answer in the first meeting. A team that jumps to solutions before understanding the problem is optimizing for closing the deal, not for building the right thing.
They push back on scope. If a team agrees to everything you ask for, they either don’t understand the complexity or they’re planning to charge you for the overruns later. Good teams say “we can do that, but here’s what it would mean for the timeline” or “have you considered doing this simpler thing first?”
They show working software early and often. If you’re more than four weeks into a project and you haven’t seen working software, something is wrong. No amount of documentation or status reports substitutes for a working demo.
They talk about maintenance from the start. Software isn’t done when it launches. A team that only talks about building and never mentions what happens after launch is either inexperienced or hoping you won’t notice.
Red Flags
They guarantee fixed timelines on complex projects. Certainty on a software project is inversely proportional to the project’s complexity. Anyone who guarantees a six-month timeline on a complex project before doing thorough discovery is either lying or planning to cut scope when reality hits.
They won’t show you previous work. Case studies, references, and code samples exist for a reason. If a team can’t point to specific projects they’ve shipped, ask why.
They skip discovery. If a team goes straight from sales call to proposal with a detailed timeline and budget, they’re estimating based on assumptions, not understanding. That estimate will be wrong, and you’ll pay for the delta.
For a deeper look at choosing the right team, our guide on hiring a software development agency covers the full evaluation framework.
How Long Does Custom Software Development Take?
Timelines depend on scope, but here’s what’s realistic:
| Project Type | Discovery | Build | Total |
|---|---|---|---|
| Simple internal tool or automation | 1 week | 3-4 weeks | 4-5 weeks |
| Standard business application | 1-2 weeks | 6-8 weeks | 8-10 weeks |
| Complex multi-integration platform | 2-3 weeks | 10-16 weeks | 12-19 weeks |
| Enterprise system | 2-4 weeks | 16-24 weeks | 18-28 weeks |
These are working software timelines, not “first line of code” timelines. The discovery and design work front-loads the decision-making so the build phase moves faster.
If a team in Chicago, San Francisco, or anywhere else quotes you something dramatically faster or slower than these ranges for a comparable scope, ask how. Sometimes the answer is reasonable — a very focused scope, reusable components, or deep domain expertise. Sometimes the answer is that they’re underestimating the work or planning to cut corners.
FAQ
What does a software development process actually look like day-to-day?
On a typical project, our team works in two-week sprint cycles. Each day includes focused development work, code reviews, and internal syncs. Every two weeks, we demo working software to the client, discuss feedback, and plan the next sprint. Between demos, you have direct access to the team through Slack for questions and quick decisions.
How long does custom software take to build?
Most projects take 8-16 weeks from kickoff to launch. Simple automations and internal tools can ship in 4-5 weeks. Complex platforms with multiple integrations can take 6+ months. The biggest factor is scope — a well-defined project with clear boundaries moves much faster than one where requirements are still being figured out during the build.
How much does custom software development cost?
Automation projects typically run $10,000-$30,000. Internal tools and business applications range from $35,000-$100,000+. Enterprise systems with complex integrations start around $100,000 and scale from there. The most important factor isn’t the upfront cost but the total cost of ownership compared to the manual processes or SaaS workarounds you’re currently paying for.
Should we build custom software or buy off-the-shelf?
Build when your process is genuinely different from what off-the-shelf software assumes. If you’re spending more time working around your current tools than working with them, the workaround cost often exceeds the cost of building something that fits. Buy when your needs are standard and the market has a tool that handles 90%+ of what you need without modification.
How do you handle projects when requirements change mid-build?
We expect requirements to change. Small changes get absorbed into the current sprint. Larger changes trigger a trade-off discussion — we’ll show you what adding the new requirement means for timeline and budget, and what could be deferred to accommodate it. The goal is always to give you the information you need to make a good decision, not to penalize you for learning something new about your own business.
Ready to Talk About Your Project?
If you’re evaluating your options for a software project, we’re happy to walk through how our process would apply to your specific situation. No pitch deck. Just a conversation about what you’re trying to accomplish and whether we’re the right fit.
Schedule a conversation with Owen to talk through your project.
Related reading: The CTO’s Guide to Outsourcing Software Development covers how to evaluate and structure an engagement with an external development team.
Written by Owen Auch, founder of Scott Street. Owen previously led engineering teams at Orb and Asana.