Stacks
That ten-year-old PHP service is welcome.
Agents learn your repo first, then work the way it already works. No rewrite and no new framework slipped in.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
PHP, Node, Python, Java, .NET, Go.
- 2
React, Next.js, Flutter, React Native.
- 3
SQL and NoSQL databases.
- 4
Legacy code included.
What we work in, and how we fit in.
Web, mobile and databases.
- Supported
The list
If yours is not here, ask. A short email gets a straight answer.
- Backends. PHP and Laravel, Node.js, Python and Django, Java and Spring, .NET, Go.
- Frontends and mobile. React and Next.js, Flutter and React Native.
- Your patterns
New code looks like your code
Agents reuse the helpers already in your repo instead of bringing new ones.
- Your conventions. New code follows the patterns already there.
- No rewrite pitch. We build what you asked for, in what you have.
Your existing code stays the starting point, whatever language it is written in
- Most teams do not start from a clean sheet. They have a web app that grew over many years, a mobile app that was rebuilt twice, and a database with tables nobody fully remembers. The work you need done is rarely a fresh build. It is a change to something that already runs, and that already has customers depending on it.
- Our work starts from that reality. Agents read the repository you give them before they plan anything. They look at how the code is laid out, which helpers already exist, how errors are handled and how tests are written. The request is then shaped to fit that code, not to fit a framework we happen to like.
- This means you do not have to move to a new language to get help. If your core service is written in PHP, Java or .NET, the work can be done in that language. If your front end is React, Flutter or React Native, the work follows that front end. The stack you run today is the stack we work in.
- It also means you do not have to clean up the whole codebase first. A request for one new screen should not turn into a rewrite of everything around it. Changes stay in the area the request touches, and the pull request shows exactly what moved.
- Your team keeps the final say. Every pull request lands in your repository as an ordinary change. Your engineers can read it, question it and decide whether it merges, the same way they would review a change from a colleague.
- The result is simple to describe. You get changes that look like they belong in your code, in the language and tools you already use, and your team sees them as normal pull requests.
Work on a ten-year-old service without a rewrite pitch
An old service carries years of decisions.
Some are good ones. Some were made under pressure and never revisited. A typical team cannot afford to fix all of it, and it should not have to. Most of the time, the goal is a small, safe change that does not break anything that already works.
We aim for exactly that.
The request is written as a list of stories, and each story says what must change and what must stay the same. The acceptance criteria include the behavior that already exists and should not move. Tests check both the new behavior and the old behavior that the change touches.
A legacy codebase often has no tests, or only a few.
That is common, and it does not stop the work. The tests we write for a change cover the parts the change touches. Over time, those tests become a safety net that your team can extend, and they do not need a separate project to set them up.
We do not pitch a rewrite as the price of entry.
If a rewrite is the honest answer to a request, we will say so in writing, and you decide whether to go that way. Most requests do not need one. A new report, a fixed workflow or an extra field can be added to the existing code without touching the rest of the system.
Old code also has old quirks.
A date format that looks wrong, a helper with a strange name or a function that does three jobs. Agents read these as part of the repository, not as mistakes to correct on the way. If a quirk is a real bug, the request should say so, and we will treat it as its own story with its own check.
The honest way to judge this is to make one small change on your oldest service your first request. The $500 prepaid minimum still applies. Pick a change you already know well. Read the pull request as your team would read it. If it looks like something your own engineer might have written on a good day, the fit is working.
Backend and database work lands in the stack you already run
On the back end, we work in PHP and Laravel, Node.js, Python and Django, Java and Spring, .NET and Go. These are the languages and frameworks we work in. Each one has its own habits, and agents are asked to follow those habits instead of importing a style from somewhere else.
For PHP and Laravel, that means using the service providers, form requests and models the project already has. For Node.js, it means following the module style, error handling and async patterns already in the repository. For Python and Django, it means working with the apps, models and settings you already have.
For Java and Spring, it means respecting the configuration, the dependency wiring and the layering that already exist. For .NET, it means following the project structure and the conventions your team uses for services and data access. For Go, it means keeping the code simple and idiomatic, with the packages the repository already uses.
Back-end work often touches an API that a front end depends on.
We treat that contract as a fixed thing unless a story says it changes. If the contract must change, the change is written as its own story, with the front-end and back-end checks it needs. Nothing changes the shape of an API by accident.
Background jobs, queues and scheduled tasks are part of many back ends.
A change to one of them is a change to how work runs, and it needs care. The acceptance criteria should say what happens when a job fails, retries or runs twice. We check those cases before the pull request is raised.
On the data side, we work with SQL databases and NoSQL databases.
The work follows the schema, the migrations and the access patterns that your team already uses. A new column should arrive through the same migration path as the rest of your schema, not through a side door.
Database changes are written as their own stories where possible.
A story that adds a field is easier to review, easier to test and easier to undo than one that adds a field, changes a query and rewires a report all at once. Each story states what it reads and what it writes.
Migrations deserve a clear check.
The acceptance criteria should say what happens to existing rows, what happens when the migration runs twice and what a rollback looks like. We would rather write those lines into the story than leave them for a reviewer to guess at.
We do not move your data to a new store as part of a feature request.
If a request needs a different database, that is a separate decision, and it should be written as its own story with its own review. Your team makes that call.
Credentials and production data need care.
Do not send production passwords, live customer records or full database dumps with a request. Use made-up test data, and keep real secrets out of the repository. If a task truly needs production access, talk to us first so the handling is agreed in writing.
PHP and Laravel.
Node.js.
Python and Django.
Java and Spring.
.NET.
Go.
SQL databases and NoSQL databases.
Screens and code that look like your team wrote them
- On the front end, we work in React and Next.js. On mobile, we work in Flutter and React Native. Each one follows the component structure, styling approach and data-fetching pattern that your repository already uses. A new screen should look like it was built by the same team as the screens next to it.
- Front-end work is judged on what a person sees and clicks. That is why the acceptance criteria are written in plain words, and why a person clicks through the feature before the pull request is raised. A check that only confirms code runs does not tell you whether a button makes sense.
- Mobile work adds a few extra questions. Does the screen work on a small phone? Does the layout hold when text is larger? Does a slow network show a clear message? Those questions belong in the criteria when they matter for your product. If they matter, write them into the request, and the manual check will look for them.
- Next.js and other frameworks that render on the server need extra care. A change that works in the browser can still fail on the server, or the other way round. We ask for the rendering behavior to be written in the criteria, so a reviewer knows what was checked and what was not.
- Shared code between web and mobile is common, and we handle it with the same care as the rest. A change to a shared module is its own story, with its own checks, because it can reach both platforms at once. Nobody should find out at release that a shared helper moved.
- Every repository has its own conventions, and most of them live in people's heads. Naming rules, folder layout, the way errors are reported, the order of imports and the style of tests all count. A reviewer notices immediately when a change ignores them, and the review turns into a lecture about style instead of a discussion about the work.
- Agents read the existing code before they write anything. They look for the closest example of the same kind of change, and they copy its shape. If your repository has one good example of a form, a report or an API route, the new code tends to follow it. The first pull request should look like it came from your team.
- Reuse matters as much as style. A repository often has a helper for dates, a wrapper for API calls or a component for tables. Agents are asked to use those helpers instead of adding new ones. Your reviewer then sees fewer new pieces to check, and the codebase grows more slowly.
- Naming is one of the first things a reviewer checks. New names should match the words your product uses. If your team calls a customer an account in the code and a client on the screen, the new code should follow the code. The PRD can note any term that needs a decision before the build.
- Old code has habits too. Some teams write a short comment above every public function. Some never write comments. Some always use a certain logging helper. Agents are asked to match those habits, and a pull request that looks like the rest of the repository is easier to review and easier to live with.
- The first pull request is the best place to check all of this. Read it as your reviewer would. If something feels off, say so. A short note tells us what to match next time, and the next request will be closer to what your team expects.
Stacks compared with a hire, an agency and a coding tool
A hire who knows your stack can be the right choice.
A good engineer brings judgment, and that judgment is worth a lot on a hard problem. The cost is time. One person can only read and write so much code in a week, and the work they take on is shared across your roadmap, your meetings and your on-call rota.
An agency that knows your stack can also be a good fit.
It brings a team, and a team can cover more ground than one person. The usual trade-off is the scope document. The agency sets a price for a block of work, and changes to the block are negotiated. Stack fit is often assumed at the start and proven only later, when the code is in front of your reviewers.
A coding tool can read your repository and write code in many languages.
That is useful, and it is fast. What a tool does not supply on its own is the discipline around the code. Someone has to read the existing helpers, check the conventions, run the tests and look at the screen. If your team does those jobs, the tool can fit in. If nobody does, the code arrives faster and the review gets harder.
Our approach sits between those three.
The stack is read from your repository on every request. The conventions are copied from the closest example in your code. The tests and the manual check run before the pull request exists. Your team still reviews and merges. The difference is that the stack fit is checked on each request, in writing, before anything is built.
Ask a hire, an agency or a tool the same three questions.
Which part of my stack do you know well? How do you learn my conventions? What do you check before my reviewer sees the change? The answers are plain facts you can compare, and a vague answer tells you what you need to know.
The fair choice depends on the work.
For a single deep problem in one service, a senior hire may be the right answer. For a long list of changes across several services, a steady flow of stories may fit better. For a whole new product, an agency may be the right partner. Pick the shape that matches your work. Your first change runs inside the prepaid 100-story minimum.
Hard questions about stacks, answered in full
Is my stack on the list?
Check the list on this page first. If your backend, front end, mobile app or database is not there, write to us. Give us the language, the framework and the version, and we will answer plainly whether the work fits. We will not claim support we cannot show.
Will you move us to a new framework?
Not as part of a normal request. A feature request is worked inside the stack you already run. A move to a new framework is a separate decision, with its own plan, its own risks and its own price. We will say so in writing if a request is really asking for one.
What about a very old version of a language?
Tell us the exact version when you write to us. The version decides which tools and patterns are available, and we want to be honest about what the work can cover. We will not pretend an old version is current.
Can you work in a monorepo with several apps?
Yes, if the request names the app and the folder it touches. Each story should say where the change lives. That keeps the pull request small and stops changes from leaking into the other apps by accident.
Do you need access to our production systems?
No. Work is done in your repository and lands as a pull request. If a task truly needs production access, we agree how it is handled before any work starts, and we do not ask for live credentials in a normal request.
What if our stack is a mix of old and new?
That is the most common case, and it is the one this page was written for. Name the old parts and the new parts in the request. The PRD will show how each story touches them, so you can see the risk before you approve.
How do I start if my stack is unusual?
Write to us with a short description of the stack, the repository and the request you have in mind. A short email is enough for a first answer. If the work fits, the next step is a PRD for you to read and approve, with nothing built until you say yes.
Will my team need to learn a new tool?
Your team reviews ordinary pull requests in the tools it already uses, so the review step does not change. Nothing about the merge process is new, and your engineers keep the same final say they have today.
What if our repository uses a build step or a test command that is unusual?
Tell us the build and test commands in the request. The work follows them, and the tests run the same way your own team runs them, so the results mean the same thing to your reviewers.
Do you support languages that are not on the list?
Ask first, with the language and version in the message. We will tell you plainly whether the work fits, and we will not claim support for a stack we have not shown you work on. A clear no is more useful than a vague yes.
Send us your stack and judge the fit on one real change
- The best test of fit is a real change in your real repository. Pick one request that your team would be glad to have done. Keep it small enough to review in one sitting, and clear enough that you can say what done looks like.
- Check the PRD first. It should name the files and areas your change touches, and it should mention the existing patterns the work will follow. If the PRD reads like a generic plan for a different product, that is a sign the fit is wrong, and you should say so before approval.
- Then read the pull request as your own engineer would. Does it match your conventions? Does it reuse what is already there? Are the tests the kind your team writes? If the answers are yes, the stack is working for you. If not, tell us what to change, and we will adjust the next request.
- If your stack is not on the list, write to us. A short email gets a straight answer. Use the button on this page to send it. Include the stack and the version, a rough size of your repository and one request you would like to see built.
- A reply from us will name the parts of your stack that fit well and the parts we would need to see first. That reply is the start of the PRD conversation. Nothing is built until you have read a PRD and approved it, so the fit is settled on paper before any code is written.
Your stack, with versions.
One real request, small enough to review.
Your existing conventions, in a sentence or two.
Questions, answered plainly.
Can’t find yours? Write to a founder.
1Will this work on our old codebase?
Yes. PHP, Node, Python, Java, .NET and Go are all in scope, along with React, Flutter and SQL or NoSQL databases. Agents read your repo first and follow the patterns they find.
2Who 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.
3Is 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.
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.