Code ownership
Your repo, your review, your code.
Work arrives as an ordinary pull request in your repository. There is no platform to leave, and nothing to export if you stop.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
Ordinary pull requests.
- 2
Your branch strategy.
- 3
Your team decides what merges.
- 4
No lock-in.
If you stop tomorrow, nothing breaks.
Because everything is already where it should be.
- 1
You own what you merge
The code lives in your repository, in your history, under your review.
- 2
Nothing proprietary in the way
New code follows the patterns already in your repo. It does not depend on a tool of ours to keep running.
- 3
Your team keeps the final say
Your engineers read every pull request and decide what merges. An unmerged PR changes nothing in your product.
- 4
Agents do need to read your code
They cannot follow your patterns without reading them, so access to your repository is part of the work. The Security page says what to ask us about that.
Your code arrives in your repo, in the place your team already works
- Think about the next feature you have been putting off. It does not arrive as a file from a vendor, a zip you have to unpack, or a login to a dashboard you will forget about. It arrives as a pull request in your own repository, next to the work your engineers do every day.
- That changes the shape of the week. Your product lead writes the request in plain English. You read the PRD and approve the scope. A pull request then shows up in the same place your team already reviews code. Nobody has to learn a new platform, and nobody has to hunt for what changed.
- Think about how much time disappears when a feature sits in the wrong tool. Someone exports something, someone else pastes it somewhere, and a third person tries to work out which copy is current. When the output is ordinary code on a normal branch, that friction goes away. The change sits in the same history as every other change, under the same review rules.
- Here is a plain example. Your admins ask for a CSV export on the reports page. The PRD lists four user stories and a cost of $20, and you approve it. Within three business days, a pull request appears in your repository with its tests attached. Your engineers open it, read it and decide what happens next. The whole ownership question gets answered by that one review.
- You also keep the freedom to stop. Because the code lives in your repository, stopping does not mean rebuilding anything or moving files out of a system. The merged work is already where it belongs. Your team can keep building on it with us, with someone else, or on its own.
- The rest of this page explains how that works in practice. It covers what you get, what you can check, what to ask before you start, and what to expect if you ever decide to stop.
- In a normal week, the change is small and steady. A request goes in. A PRD comes back the same business day, as we aim. Your approval starts the work. The pull request arrives within three business days, and your engineers review it the same way they review anything else.
You keep the code, the history and the last word
Ownership shows up in how the work is delivered, every time a request is merged.
Here is what that looks like for your team.
Once a change is merged, it is ordinary code.
It is written the way your own engineers write code, in the language and framework you already run. Your team can read it, change it, debug it and extend it in the same way it handles every other module in the product.
That is what your repo, your review, your code means in practice.
You get changes you can read, test and maintain yourself, using tools you already have.
Your team also keeps the power to say no.
A pull request that does not meet your standards does not merge. It is not forced into the product, and it is not released by default. Your review rules are the gate.
Ownership also protects your options later.
If you change how you get work done, the code does not move with it. Your next engineer, your next vendor or your own team can pick up exactly where the work stopped, because the history and the tests live in your repository.
Reviewers also get what they need in the same place.
The tests arrive in the pull request, so they can run them without asking for anything else. The diff sits next to the PRD it came from, so they can check the change against the criteria you approved. These details decide whether a merge feels routine or feels like a risk. Routine is the goal.
Think about what your team already holds.
Your repository has a history of who changed what, when and why. Your branch rules and review rules are already written down. The new work does not replace any of that. It adds to a record that was already yours, in the format your team already reads.
Ask yourself a simple question about any outside supplier.
If they stopped answering your emails tomorrow, what would you still have? With this route, the honest answer is the full change history of every feature shipped into your repository, with the reasons written in the PRD and the proof in the tests. That is the standard we hold ourselves to.
Ownership also means you set the pace.
You decide how many requests to send in a month, within the minimum you agreed, and you decide which merged work your team ships first. No one else sets your merge calendar or decides when your releases go out.
The code lives in your repository and your commit history.
Your engineers review every pull request and decide what merges.
Your branch strategy and review rules stay in place.
New code follows the patterns already in your repo.
Nothing needs a special runtime from us to keep running after the merge.
What you can check on every pull request
- Every request follows the same path. These are the parts of that path that protect your ownership, and what you can check for each one.
- Checking each item takes minutes, not days. Open the pull request. Check the diff against the criteria in the PRD. Run the tests on your own machine. Look for a helper that already existed and was ignored. Each check is something your engineers already do for any change, so none of this needs a new skill.
- Start with the PRD. It is the agreed scope for the work. If a criterion is vague, say so before you approve it. A clear PRD makes the review short, because reviewers are checking against a list rather than guessing what the feature should do.
- Next, read the diff the way you would read a colleague's change. Look for names, file layout and error handling that match the rest of your code. If something new appears, ask why it was needed. A good answer is a short one, and it tells you whether the change fits your product.
- Then run the tests. They belong in the same pull request, so your reviewers do not have to write them first. If a test fails on your machine but passed in our run, treat that as a real finding. Tell your account manager, and keep the pull request open until the gap is explained.
- Permissions are the other half of ownership. Access to your repository is set by you, and it should be as narrow as the work. Ask for read and write access only to the repositories in scope. If a task seems to need something wider, that is a conversation to have in writing before anyone is given access.
- Here is how a reviewer might walk through the CSV export change from start to finish. Open the PRD and read the four stories beside the diff, so every story has a visible place in the code. Check that the export keeps the filters the admin set. Look at how large reports are handled, because that is where timeouts usually hide. Read the failure path and make sure the error message gives an admin something to act on. Look for an existing download helper, and ask why a new one was needed. Each step is a normal review step, and none of them needs a tool from us.
- Finally, do the part no tool can do for you. Decide whether the change is right for your product. Merge it, change it or close it. That decision stays with your team every time, and it is the one check that matters most.
- Then close the loop. Tell your account manager what you found, good or bad. Named feedback shapes the next PRD, and it is the fastest way to make the next pull request easier to merge.
The pull request lands on your repository, under your branch strategy.
Tests ship in the same PR:
unit, integration and browser tests.
The PRD lists the user stories and acceptance criteria you approved.
Agents reuse helpers and patterns that already exist in your code.
Deployment stays with you unless you choose to hand it to us.
A person checks the feature against the criteria before your team sees it.
Your engineers stay in charge of the code they know best
Good engineers take pride in their codebase.
They know where the tricky parts are, which helper to reuse, and which habits the team agreed to drop years ago. Nobody wants a stranger's habits sitting in the middle of that work.
The worst kind of outside work is the kind that quietly brings its own style.
The code runs, so everyone accepts it for a week. Then your team has two ways of doing the same thing, and the cleanup falls on the engineers you can least spare.
Our setup is built to avoid that.
Agents read your repository before they plan. They follow the patterns they find there. The aim is a change that looks like something one of your engineers could have written on a good day, not a demo that needs rewriting before it can be merged.
We do not have customer quotes to show you yet.
We are onboarding our founding cohort, and we would rather say that plainly than borrow someone else's words. What we can offer is the pull request itself, along with the criteria it was checked against.
Picture the first merge.
Your team reads the pull request at its normal pace. The tests pass on their machines. The diff reuses the helper that already exists. Nobody has to call a meeting to explain where the code came from, because the whole record sits in your repository, from the PRD to the last commit.
Picture the second one, and the tenth.
The reviews get shorter, because your engineers recognize the patterns. The questions get sharper, because the PRDs are clearer. The team stops treating agent work as a special event and starts treating it as one more source of changes to review.
The difference shows most in the talk after review.
Engineers discuss the change in the terms they already use, such as the module it touched and the test it needed. They talk about the code, not about the tool that wrote it. That is the sign the work has been absorbed into the codebase rather than sitting beside it. Time that used to go to fixing style drift now goes to design and risk.
That is the feeling we want you to have:
the calm of a change that fits. Your engineers keep their standards, your product keeps its shape, and the backlog starts to move.
How ownership differs across hiring, agencies and coding tools
- There are three usual routes to more engineering capacity. Each one answers the ownership question in a different way. Here is how they differ, so you can see where your team fits best.
- Hiring gives you the strongest ownership. The people write code inside your team, under your rules, from their first day. The cost is time. Hiring takes months, and a new engineer needs a ramp period before the code they write fits your product well.
- Agencies vary a lot. Some hand over code in your repository. Some keep work in their own systems until a final handover. Some sell you a finished app with its own setup. Read the contract for how code moves to you, when it moves, and what you can do with it afterwards. If those answers are not written down, the ownership is not settled.
- Coding tools keep the code where you put it. The output lands in your own project, so ownership is simple. The gap is the work around the tool. Someone on your team still writes the request, steers the agent, decides the design and runs the checks. That person's time is the real cost, and the ownership question now sits with whoever holds the prompt.
- Our route is closest to your own team's route. Work arrives as a pull request in your repository, and your engineers review it. The scope is written down in a PRD before anything is built. You pay per completed user story, not per seat or per hour. The trade-off is that you give up direct control of each step, so you need to trust the PRD and the review.
- A fair test of any route is what you keep if you stop. With hiring, you keep the knowledge in your team and the code in your repository. With agencies, you keep what the contract says you keep. With coding tools, you keep the files, but the working habits stay with whoever drove the tool. With our route, you keep the pull requests, the PRDs and the tests.
- Each route also leaves a different paper trail. Hiring leaves employment records and your own review history. Agencies leave whatever the contract and the handover describe. Coding tools leave the files and whatever notes your engineers keep. Our route leaves the PRD, the pull requests and the tests inside your repository. Look at the trail you would want to have in a year, and choose on that basis.
- Choose the route that matches your situation. If you have engineers with spare hours who enjoy driving agents, a coding tool may suit you well. If you need people in the room every day, hire. If the problem is a backlog that keeps growing, and you can review pull requests, the pull request route is the one we fit.
Hiring:
strongest ownership, slowest start.
Agencies:
ownership depends on the contract and the handover.
Coding tools:
you keep the code, but someone on your team must drive it.
AgentCTO:
pull requests in your repo, scope approved first, $5 per completed story.
Hard questions about ownership, answered as far as we can today
Ownership questions deserve plain answers. Some of them depend on details we settle with you in writing, and we would rather say so than guess. Here are the ones we hear most often.
If your engineers ask what an agent actually read, answer that question in writing before access is granted. Agents and our team read the repositories in scope. Ask us what the narrowest access is.
The common thread is simple. Every answer you need should be in writing before you pay. If an answer is vague, that is a good reason to wait and ask again. A clear answer is worth more than a fast start.
Will you keep a copy of my code?
What happens to copies of your code while work is in progress is a question we settle with you in writing before you start. Ask it in your first email, and do not sign anything that leaves it unclear.
What happens if you stop trading?
Because the code already lives in your repository, the merged work stays with you. You do not need us to keep the code running. Still, ask how access is removed and how any unfinished work is handed over if the engagement ends.
Will my engineers be replaced?
No. We take requests and build them. Your team reviews every merge and decides what ships. We do not replace your team, and we would not be a good partner if we tried.
Do agents need to read my code?
Yes. Agents cannot follow your patterns without reading them. Give access only to the repositories in scope, and ask us to list exactly what that access allows. Access should be as narrow as the work.
Is an AI-written change safe to own?
Treat it like any other change. It must pass the tests in the pull request, meet the acceptance criteria in the PRD, and pass your own review. If it would not pass your review, it has not earned the merge.
What if my reviewers disagree with a choice the agents made?
Your reviewers decide. A change they reject does not merge into your product. Tell your account manager what they found, so we can take it into account on the next request.
Do I need to change how my team works?
No new tool is needed. Your team reviews pull requests the way it reviews them now. The only new habit is reading a PRD before you approve a request, and most product leads already do that for internal work.
What if I want to bring the work in-house later?
Then you keep going. The repository holds the code, the tests and the history. Your engineers can pick up any part of it. We would rather you could leave easily than stay because you had no other choice.
What if we decide to stop partway through a feature?
Ask us in writing how unfinished work is handled before you start. Merged pull requests stay in your repository. A story that has not met its acceptance criteria has not been completed, and the refunds and billing page explains how prepayment works. Read those terms before you approve the first PRD.
What if a merged change causes a problem in production?
Deployment stays with you unless you hand it to us. Your release process decides when code reaches users, and your monitoring catches problems the same way it does now. A change that caused a problem is a finding for your review and our account manager, and it is handled like any other defect.
Who can see what we merge?
Your repository permissions decide who on your side sees it. Our agents and team read the repositories in scope, and AI model providers may process them. Ask us which people on our side will work on your repository, and ask for the narrowest access the work needs.
Can a new engineer pick up the work later?
Yes. A new hire, a new vendor or a new internal team can read the repository, follow the history and run the tests. You do not need a special guide to start, because the code follows the patterns your team already uses.
Who decides what the agents build?
You do, through the PRD. The PRD lists what will be built, and you approve or change it before any building starts. The scope is never a surprise.
Keep your repo, and send the first request from it
- Your repository is the asset that matters here. It holds your history, your standards and the work your team has already done. Our job is to add to it through pull requests you can read, test and reject.
- Make a short list before you prepay. Write down who reviews, where the repository lives, who can access it, what you keep if you stop, and which questions are still open. If any line stays blank, do not prepay yet.
- Start with one feature you have been postponing. Write it in plain English, tell us where the code lives and who reviews it, and we will set up access with you. Use the email button on this page to send it.
- Before you prepay, ask the questions that matter to you, in writing. Ask about access. Ask who sees your code and which model providers apply to your work. Ask who on your team approves PRDs and who reviews pull requests. Those answers belong on paper, in your inbox, before any work begins.
- When the first pull request lands, open it in your own repository. Read the PRD it came from, run the tests, read the diff and decide. That single review will tell you more about ownership than any page on this site.
- Keep the first pull request as your reference. Note how long the review took, what you changed and what the tests caught. That note will tell you more about the next request than any sales page.
Questions, answered plainly.
Can’t find yours? Write to a founder.
1Who owns the code?
You do. Work arrives as a pull request on your own infrastructure. Your repository, your stack, your review process. To do the work, our agents and team read your repository under the access you agree, and AI model providers may process it. See the security page for details.
2Is this right for us?
It fits if you have a repo, a backlog, and someone who can review pull requests. It does not fit if nobody on your side can review code, because your team makes the final call on every merge.
3What if I need help along the way?
You get a named account manager. That is a real person who tracks every request through to the merge, at zero extra cost. Founders are one email away too.
Send the feature your roadmap has carried for a quarter.
We open the PRD the same business day. Three business days after you approve it, a pull request is in your repo. Judge us on the merge.
Minimum 100 user stories a month, $500 prepaid. No mail app? Write to udit@tinycheque.com.