Fixed-price engineering sprints
Your engineering team,without hiring one.
You tell me what needs to exist. I plan it into five-day sprints, we ship every week, and you see it working. Fixed price per sprint. One month notice to stop.
EUR 750 per sprint. Most projects run four to twelve. Buy one first if you want.
EUR 750 / sprint
10 tickets / week
Start in two weeks
One month notice to stop
Tell me what you are building.
If it looks like a fit, we spend thirty minutes on it. After that call I will write up the actual first sprint for your product, ten tickets, in my own words, and send it to you. No charge and no obligation. You keep it either way.
Cancel with one month notice. No commitment beyond the block you buy.
The backlog is not moving.
You have a product to build and no engineering team. Maybe there is a rough prototype. Maybe there is only a document. Either way the backlog is not moving, and hiring a developer means three months of searching and a salary you are not ready to commit to.
We become the engineering function. You decide what needs to exist. We build it, review it, test it, and tell you honestly when something is not ready.
- #01Checkout still isn't live end to endTo do
- #02Onboarding half-rebuiltTo do
- #03CSV import never finishedTo do
- #04Webhook retries are flaky in productionTo do
- #05Migrations still run by handTo do
Waiting on an engineer you have not hired yet
Five days, ten tickets, every week.
Whatever you need built, I turn into a sequence of five-day sprints, each with a named outcome, and we agree exactly what is in each one before it starts. Nothing is a surprise and nothing is estimated by a machine.
A sprint is five working days and ten tickets. Ten is the pace we hold, week after week. A mid-level developer in Berlin ships two to four tickets a week.
Ten tickets a week from a small team is possible because the engineer works with AI coding tools all day rather than typing every line. Nothing ships just because a tool wrote it. Every pull request is code reviewed, and a person checks the release before it reaches you.
Every project gets one engineer working your backlog daily, one QA engineer checking every release, and me on planning and scoping.
Every sprint includes
- Ten tickets scoped, implemented and code reviewed
- One senior engineer, named, working your backlog every day
- Automated code review on every pull request
- Human QA before anything reaches production
- A weekly planning call with me
- Someone accountable for whether it actually works
Tickets go live as each one clears QA, and all ten land inside the sprint. If anything ever slips, we tell you which before the sprint ends rather than after.
- #01Done
Finish the half-done CSV import
- #02Done
Trailing-comma rows break the parser
- #03Done
Make webhook retries idempotent
- #04Done
Add pagination to the list view
- #05Done
Reminders fire early after DST
- #06Done
Move file uploads to object storage
- #07Done
Soft-delete accounts, stop wiping rows
- #08Done
Invite emails hit spam, fix SPF
- #09Done
Audit log for admin actions
- #10Done
Framework upgrade, run test suite
EUR 750 a sprint. Nothing hidden.
EUR 750 per sprint, billed in advance. Work is usually scoped as a block. Checkout live end to end and onboarding rebuilt is roughly four sprints: four weeks, EUR 3,000, and you know what lands at the end of each one.
Buy one sprint first if you want. If it does not work, do not buy the second.
Hiring a developer in Berlin
- EUR 6,000 to 8,000 per month, fully loaded
- One person. No QA, no planning. That is your job too.
- Around three months to find the right person
- Two to four tickets a week once they are up to speed
- You manage them, review them, and carry the risk if they leave
Four sprints with us
- EUR 3,000 per month
- An engineer, a QA engineer, and me on planning. Three people, not one hire.
- Starting in two weeks
- Ten tickets a week
- Nobody to manage, and you can stop with a month's notice
The rules of the deal, in writing.
Scope locks when the sprint starts.
If you want something new mid sprint we will swap it for something already in the list. We will not quietly add it and miss the commitment.
A ticket is defined in writing.
A piece of work a senior engineer finishes in under a day, give or take. We write each one down before the sprint starts so we are counting the same thing.
If we fall short, it carries over free.
If we do not finish what we committed to, the remainder moves into the next sprint at no extra charge. You never pay twice for the same ticket.
Billed in advance, cancel with a month's notice.
There is no commitment longer than the block you have bought.
Your data stays in Europe.
Every client we have is in Europe, so this is not a new conversation for us. We run production and internal environments on the server of your choice (most of our clients prefer Hetzner), and your data stays where you want it kept.
Access is limited to what a ticket needs and removed when the engagement ends. Every DeutNet employee completes GDPR training every six months.
A person, not an account manager.
I am Anoop. I spent five years in Berlin and Bavaria as an engineering manager at German startups. I hired engineers there, ran teams there, and learned how German founders expect work to be handled.
That focus on Europe is not an accident. I know how European founders scope work, give feedback, and judge a vendor — because I spent those years on their side of it.
DeutNet is small on purpose. You get me on the planning call.
Things we have built and still look after.
Three of the products we have built and still run in Europe today. Two started as an idea with no code and no engineers. Client names and interface details are anonymised, because that is what we would do with yours.
SEO tool
A web app that helps a founder run and sell SEO work without an agency behind him.
Built from an idea, no code at the start.
Logistics platform
A booking and tracking product for a European logistics startup, taken from a rough prototype to production.
Rebuilt from a founder's own prototype. Shipping weekly.
Security product
A cross-platform security application for Windows, macOS and Android.
Idea to launched MVP with no in-house engineers.
The people who build and test client products.
These three work on client projects today. They are the standard of person we hire, and how a new project would be staffed. Full-time employees, not freelancers — the team on your backlog does not change.
In their words, not ours.
What truly sets DeutNet apart is the integrity and reliability of its leadership. We entrusted them with our most important new product line. Not just a vendor. A trusted partner.
Frank Satterwhite1600 Cyber GmbHLinkedInHaving reliable technical partners is crucial for our success, and that is exactly what we found in DeutNet and Anoop Nair. We know we can always count on him and his team.
Felix Groteseobuddha GmbHLinkedInOne of the most reliable and capable engineering partners I have collaborated with. Communication is clear and proactive, timelines are met without compromising quality.
Laura Kindlerecoligo GmbHLinkedInThe things you are already wondering.
Could we not just use AI coding tools ourselves?
Many founders do, for a while. The real question is whether you want your week going there. One of our longest-standing clients uses these tools himself and still works with us, because someone has to own whether it actually ships.
You are in India. What about quality and time zones?
There is three and a half hours of overlap with Berlin, so you get answers inside your working day. Every pull request is code reviewed and every release is checked by a person before it reaches you. I also spent five years working inside German startups, so we are unlikely to be far apart on how you want things done.
What if you are gone in six months?
A fair question. One of our clients is in year two. I am happy to put you in touch with a founder who has worked with us that long.
What happens after it is built?
Most clients move to a support plan once the product is live. Monitoring, dependency and security updates, and someone who knows your codebase when something breaks. Sprints start again when you want to build something new. I will not build you something and then disappear.
That is more than I expected.
Compare it to hiring. Three months to find someone, EUR 6,000 to 8,000 a month once loaded, and you manage them. We start in two weeks and you can stop with a month's notice.
What if there isn't enough work to fill a sprint?
A sprint is a fixed week at a fixed price, up to ten tickets. Some weeks fill all ten, some fewer, and it costs the same either way — you are buying the week, not the ticket. The aim is to keep a sprint full, so if your backlog is thin I will say so before it starts, and we either wait for a sprint's worth of work or spend it clearing the small things that never get done.
What if I need more than ten tickets a week?
Then we add resources and run sprints in parallel. If you have a launch date to hit, a second sprint in the same week is another ten tickets — ten becomes twenty, and it goes up from there. It scales back down the same way once the push is over. We will talk through your timeline on the first call and help you settle on the right cadence, so you are buying the pace you actually need.
Start here
Tell me what you are building.
A few lines is enough. What the product is, where it is now, and what needs to ship next. If it looks like something we can do well, we take thirty minutes on it, and afterwards I will send you the first sprint written out properly. If it is not a fit I will say so, and probably tell you who is.
Request a scoping call →