Most founders have never hired a software agency before. The process is opaque, pricing structures vary wildly, and every agency's website says the same things: "we build world class software" and "we are your technology partner." None of that tells you what happens after you sign.
We are going to walk through exactly what working with a software agency looks like, week by week, decision by decision. This is based on how we operate at Veld, but the structure applies broadly. If an agency you are evaluating does not follow something similar, ask them why.
Phase 1: Discovery and Scoping (Week 1 to 2)
Before any code is written, a good agency spends 1 to 2 weeks understanding your business, your users, and your goals. This is not a formality. It is where the most expensive mistakes get prevented.
The discovery call. This is usually a 30 to 60 minute conversation where you explain the problem, the market, and what you have tried so far. A good agency asks hard questions here: What is your budget? What is your timeline? Why now? Who is the competition? If they just nod and say "we can build that," be cautious.
Requirements gathering. The agency documents everything: user types, core features, integrations, compliance requirements, platforms (web, iOS, Android), and non functional requirements like performance and security. This becomes the scope document.
The proposal. You receive a detailed proposal with scope, timeline, milestones, deliverables, pricing, and assumptions. At Veld, we quote fixed prices for defined scopes. No hourly billing surprises. The proposal should be specific enough that you could hand it to another agency and they would build roughly the same thing.
What to watch for: Agencies that skip discovery and jump straight to a quote are guessing. Agencies that cannot give you a fixed price are hedging. Both are red flags.
Phase 2: Design and Architecture (Week 2 to 4)
Once the scope is agreed upon, the team splits into two parallel tracks: design and architecture.
Design. Wireframes come first, low fidelity layouts that show structure without visual polish. You review these, provide feedback, and iterate. Then high fidelity mockups add color, typography, and interaction details. By the end of this phase, you know exactly what every screen looks like before a single line of code is written.
Architecture. The engineering team designs the system architecture: database schema, API structure, authentication flow, deployment infrastructure, and third party integrations. This is documented and reviewed with you, especially the decisions that are expensive to change later.
What to watch for: If the agency skips wireframes and goes straight to code, they are building based on assumptions. If they do not share the technical architecture, you have no way to evaluate what you are paying for. Both paths lead to architecture mistakes that compound over time.
Phase 3: Development Sprints (Week 4 to 12+)
This is where the software gets built, typically in two week sprints with a demo at the end of each one.
Sprint planning. At the start of each sprint, the team selects work from the prioritized backlog. You should know exactly what is being built in the next two weeks and what the expected deliverable is.
Daily or weekly updates. Good agencies share progress regularly. At Veld, clients get updates in a shared Slack channel or project management tool. You can see what is in progress, what is blocked, and what is complete at any time.
Sprint demos. Every two weeks, you see working software. Not screenshots. Not a presentation. Actual clickable, functional software deployed to a staging environment. This is where you provide feedback, catch misunderstandings, and reprioritize.
What to watch for: If you go more than two weeks without seeing working software, something is wrong. If feedback from a demo does not appear in the next sprint, the team is not listening. Transparency is not optional, it is how trust is built.
Phase 4: Testing and QA (Ongoing + Final)
Testing happens throughout development, not as a phase at the end.
Automated testing covers critical paths: authentication, payments, data mutations, and business logic. These run on every code change to prevent regressions.
Manual QA covers user experience, edge cases, and cross device testing. The agency's QA team tests on real devices, real browsers, and real network conditions.
User acceptance testing (UAT). Before launch, you and your team test the product against the original requirements. This is your opportunity to confirm that everything works as expected. Issues found during UAT get fixed before launch.
When we built Traderly, UAT revealed that the real time trading notifications were slightly delayed on older Android devices. We caught it before launch, optimized the WebSocket handling, and shipped with sub 200ms notification delivery across all platforms. That is the kind of issue that only surfaces in real device testing.
Phase 5: Launch (Week 10 to 14)
Launch is not just pressing a button. It is a coordinated process.
Infrastructure setup. Production environment, domain configuration, SSL certificates, CDN, monitoring, error tracking, and backup systems all need to be configured and verified.
Data migration. If you are replacing an existing system, data needs to be migrated and validated. This is often the riskiest part of a launch and should be rehearsed at least once before go live.
Staged rollout. For products with existing users, we recommend a phased launch: internal team first, then beta users, then general availability. Each stage catches issues at a smaller scale.
Launch day support. The engineering team should be on standby during and immediately after launch to handle any issues that arise. At Veld, we monitor dashboards actively for the first 48 hours post launch.
Phase 6: Post Launch Support (Ongoing)
This is the part most founders do not think about until it is too late. Your product is live. Users are signing up. Now what?
Bug fixes. No matter how thorough the testing, real users will find issues. You need a defined process and response time for handling them.
Monitoring and maintenance. Someone needs to watch the dashboards, apply security patches, update dependencies, and optimize performance as usage grows. Software maintenance is not optional, it is the difference between a product that compounds in value and one that slowly degrades.
Iteration. Your initial launch is v1. User feedback will reveal what to build next, what to change, and what to remove. A good agency helps you prioritize based on data, not gut feel. This is where ongoing management becomes valuable, having a team that knows your codebase and can ship updates quickly without re learning the system.
How to Evaluate an Agency
After understanding the process, here are the signals that distinguish a reliable agency from a risky one:
Green flags: Fixed pricing for defined scope. Structured discovery before quoting. Regular demos with working software. Clear communication channels. Documented architecture. Post launch support options. References from past clients.
Red flags: Hourly billing with no estimate. Quoting before understanding the project. No demo schedule. Outsourcing the actual development to a third party. No mention of testing or QA. Disappears after launch.
For a deeper comparison of your options, our guide on choosing a development partner covers the full evaluation framework, and our comparison of agencies versus freelancers breaks down the tradeoffs in detail.
What Happens Next
If you have read this far, you are probably evaluating whether to hire an agency for a project. The next step is simple: have a conversation. A good agency will tell you honestly whether your project is a fit, what it will cost, and what to expect. A bad one will tell you whatever you want to hear.
We take on a handful of projects at a time so every one gets our full attention. Tell us about yours.