Delivery policy: timelines and what we do when something breaks

The fear I hear most from founders isn't about technology. It's about money: “what if I pay and the studio disappears?”. It's a fair fear. Plenty of people have paid a deposit, gotten a promise and ended up with no product live.

Spoken promises don't solve that fear. A written policy does. The inspiration for this page came from Linear, the project management tool, which published its zero-bugs policy in September 2025, with deadlines and numbers. This is our version for product delivery.

What Linear did about bugs

The piece, by Tuomas Artman and Sabin Roman, explains how the company decided to stop piling up bugs. The main points:

• Clear the queue. Linear had about 175 open bugs. The team paused every other project for three weeks to fix them all.
• Fixed deadlines. High-priority bugs have 48 hours to be fixed. Low-priority ones, 7 days.
• No backlog. Whoever gets the bug decides: fix it or mark it “won't fix.” Sending it to a waiting list isn't an option.
• Daily routine. Engineers start the day with the bugs assigned to them.

The result: more than 2,000 bugs fixed in a year, more than 700 in the last three months, and bugs from support often resolved the same day. When the team discussed dropping the practice, nobody wanted to. In the authors' words: “Nobody could imagine going back.”

Why publish a delivery policy

The most interesting thing Linear did wasn't fixing bugs. It was writing the rule down and publishing it. A written rule takes the decision out of the day's mood and puts it in front of the customer.

For a studio, the equivalent is stating, in writing and before the contract, what happens at each step: what it costs, when it's ready, what you get and what we do when something goes wrong.

Our delivery policy

These commitments apply to every project we do and are written into the contract.

1. Fixed price after discovery. We don't quote before understanding the problem. After discovery, the price is a number, not a range of hours.

2. Deadline written into the contract. The delivery date goes in the contract. What happens if the Studio causes a delay is also in writing, before signing.

3. One team. Design and code stay with our team, from discovery to launch, so the timeline is realistic.

4. Payment tied to delivery. Installments follow the project's steps, and each step has a deliverable defined in the contract.

5. You see the product early. We work in short cycles, and each cycle ends with a version you can click through.

6. Everything is yours. Code, Figma files, access and documentation are in your name.

7. AI agent from day one live. Every system we deliver ships with an AI agent that runs daily, flags issues, suggests improvements and checks that the data makes sense.

What happens when something breaks

Software breaks. The difference is what happens next. Inspired by Linear, we organize our response by severity:

• Critical (system down, data loss, wrong charges): first response within 2 hours during business hours, and the fix jumps ahead of everything else.
• High (core feature broken, no workaround): the fix goes ahead of the team's other tasks.
• Low (visual bug, minor issue with a workaround): the fix goes into the next delivery cycle.

How long these fixes are covered at no cost after delivery is written into the contract. After that period, the product can continue under the Ongoing evolution service.

The daily agent helps shorten the first step, which is knowing something broke. It flags issues and checks that the data makes sense every day, which in many cases lets us act before the problem reaches your users. What it finds goes into a report for you and for our in-house dev team.

What this means for you

Use this page as a checklist, with us or with any other vendor, along with the questions to ask before hiring a studio. Before you sign, ask:

1. Is the price fixed? Did it come after understanding the problem?
2. Is the deadline in the contract? What happens if it slips?
3. How many projects does the team handle at the same time?
4. How is payment tied to deliverables?
5. Are the code, design and access yours at the end?
6. What happens when something breaks, and how fast?

Whoever answers in writing has a process. Whoever only answers out loud is asking for trust.

How we do it at the Studio

We've been at this since 2014, with more than 600 projects for clients in 13 countries. Two case study timelines: LCX went live in 29 days, unifying the system for more than 10 countries in South America. AI Vou Eu, an AI travel SaaS, went live in 4 weeks.

This policy will be updated, with a date, whenever a commitment changes. If you want to launch your SaaS with these commitments in the contract, our custom system and SaaS development service starts with discovery.