You have a product to build and no engineering team. Or your team is underwater and you need experienced developers yesterday. Either way, hiring a studio is on the table.

And you've probably heard the horror stories. Or lived one. Missed deadlines, code nobody can maintain, developers who nod along on calls and then build something else entirely. Fair enough.

I work at a studio. Here's how a well-run project actually works, step by step, so you know what to expect and what to push back on.

The discovery call

The first conversation isn't a sales pitch. Or shouldn't be. It's where both sides figure out whether the project makes sense.

You'll talk about what you're building and why — not just features, but the business problem behind them. Where things stand today: is there existing code, a prototype, a Figma file, or just an idea in a doc? What the real constraints are: budget, timeline, regulation, systems that need to integrate. And who's involved: do you have devs who'll work alongside the studio, or are you handing off the whole thing?

A studio worth hiring will ask uncomfortable questions here. "What does success look like in three months?" is a lot more useful than "What features do you want?" If the conversation is all about tech stacks and hourly rates, be skeptical.

Pay attention to communication style too. People who listen more than they talk usually understand more than they talk.

Scoping

After the call, the studio puts together a scope document. Not a 50-page spec. A focused document that covers:

• What's being built, in plain language. User flows, not database schemas.
• What's out of scope. This matters more than what's in scope. Ambiguity here is where projects go off the rails.
• The technical approach, with real reasoning. "We'll use Vue.js because your team already knows JavaScript and you need to iterate fast" is useful. "We use cutting-edge technology" tells you nothing.
• Timeline broken into phases, with clear deliverables at each checkpoint.
• Cost structure: fixed price, time-and-materials, or hybrid. Each has trade-offs, and the studio should explain which fits your situation.

You should be able to read this document and understand it without an engineering background. If you can't, ask them to rewrite it. If they can't explain the plan simply, they probably don't understand it well enough.

The first week sets the tone

Contract signed. The first week matters more than any other.

Day one, the studio gets access to repos, design files, staging, communication channels. You introduce the key people and explain who decides what.

Days two through five, the team orients. They read existing code, map the architecture, identify risks, and come back with questions. Expect a lot of questions. That's good. A quiet team in week one is a team building on assumptions.

By Friday you should have a shared project board (Linear, Jira, GitHub Issues), an agreed communication rhythm (daily standup, weekly demo, Slack channel), and the first sprint planned.

Sprints in practice

Most studios work in one or two-week cycles.

At the start of each sprint, the team picks the highest-priority work from the backlog. You should be in that planning meeting. You decide what matters most, they decide how to build it.

During the sprint, the team works heads-down. You get daily async updates: what's done, what's next, what's blocked. No need to micromanage. But stay available for questions, because two days waiting on a product decision can stall an entire week of dev work.

At the end, the demo. The team shows what they built running on staging. Not slides. Working software. You click through it, give feedback, and that feedback feeds the next sprint.

After the demo, a retrospective. What worked, what didn't. It's where process problems get caught early, before they become project problems.

Communication, for real

You should never have to guess what's happening with your project. A reasonable baseline:

• Daily async updates in Slack or wherever you prefer
• Weekly demo with working software
• A project board you can check anytime
• Responses within a few hours during business hours, not days of silence

When something goes wrong, like a technical issue that shifts the timeline, you should hear about it the moment the team identifies it. Not at the next meeting, not in a report. Right then.

That's the biggest difference between a good studio and a bad one. Bad ones hide problems. Good ones bring the problem to the table and present options.

Code quality (even if you're not technical)

These things determine whether you can maintain the product after the contract ends. Ask about them.

All code should be in Git, with pull requests and code review before anything merges. If a studio commits directly to main, walk away.

Automated tests should cover critical paths. Not 100% coverage (that's often a waste), but enough that the team can ship without fear of breaking what already works.

Documentation doesn't need to be a manual. A README that explains how to run the project, an architecture overview, and comments where the code isn't obvious. Someone joining after the engagement should be able to get up to speed.

The code should have clear separation of concerns. The question worth asking: "If I hire another team to maintain this in a year, can they work with it?" The answer has to be yes.

Pushing to production shouldn't require manual steps or knowledge that only lives in someone's head. CI/CD that runs tests and deploys is standard practice.

"Will they actually understand my business?"

Fair concern. A studio works across multiple clients and industries. How will they understand your domain?

Short answer: they won't on day one. But good engineers learn fast, and the whole discovery and kickoff process exists for that reason.

You bring domain knowledge, they bring engineering. Don't expect them to become experts in your industry. Expect them to ask the right questions and translate your business logic into well-built software.

Weekly demos help a lot here. The team corrects course fast instead of spending a month building on a misunderstanding. And a good sign: by the second or third sprint, the team starts using your business terminology naturally. If they're still confused about your core concepts after a month, something's wrong.

Signs you need to step in

Not every project works out. Watch for these:

• Sprint commitments missed more than twice in a row. Once happens. Three times is a pattern.
• You're chasing updates. If you're asking "what's going on?" more than once a week, communication already broke down.
• Scope growing without anyone flagging it. Budget or timeline expanded and you didn't know? Project's out of control.
• No access to the code. You should have full repo access from day one. The code is yours.
• Team changing constantly. Some rotation is normal, but a new dev every month kills continuity.

The contract should have clear exit terms. A studio that makes it hard to leave is a studio that knows you'd want to.

What you walk away with

In a well-run project, you end up with a working product in production. Clean code in a repo you own. A deploy pipeline that runs without the studio. Enough documentation for the next team to pick up where things left off. And a clear list of what was built, what was deferred, and what makes sense to tackle next.

The best sign of a good studio? It makes itself unnecessary. If they've built something that keeps you dependent on them, they didn't do the job right.

Want to talk?

If you're evaluating studios and want a straight conversation about your project, get in touch. A call to see if it makes sense.

And if you're wondering whether your current codebase needs a full rebuild or just some targeted work, here's how to tell.