Services
The problems we work on
Each of the five engagements below opens with the problem a team would bring to it.
The five services
Your team ships every sprint and the product numbers have not moved in two quarters.
Product engineering, end to end
We embed for the full cycle. We are in the requirement conversation, we write the RFC, we put a prototype in front of real users, and we instrument the release so the next decision has evidence behind it. Shipping is the easy part to buy. Knowing what to ship is not.
You end up with
- A problem statement and an RFC for each piece of work
- A prototype wherever the question needs one
- The shipped change with its tests and written rollback steps
- Usage numbers after the release, read against what the RFC expected
You want AI in your workflow and you cannot tell which steps are safe to hand over.
AI in your delivery process
We run our own work this way. We set up the repository guidance that makes AI output predictable, move your team's effort from typing to planning and scoping, and put explicit review gates on the steps where a confident wrong answer costs money. The goal is a team that goes faster and still knows what it shipped.
You end up with
- A style guide and conventions committed to your repository
- A planning and scoping practice your team runs without us
- Written review gates for the steps where a wrong answer is expensive
The system works and nobody wants to touch it.
Modernisation
Framework and runtime upgrades, breaking up the parts of a monolith that hurt, replacing the integration that keeps waking someone at night, and cutting infrastructure cost that grew by accident. We read the system and write down how it behaves before we change anything, and you keep that document.
You end up with
- A written description of how the system behaves today
- The change delivered in small steps, each with its own rollback
You need an honest read on a codebase before you commit money to it.
Review, audit and due diligence
Architecture review, code and security audit, and technical due diligence for an acquisition or an investment. We say plainly when the answer is that the code is fine and the problem is somewhere else.
You end up with
- A written report with the findings ranked by what they will cost you
- The order we would fix them in, and what each fix involves
Your team is picking up Elixir or Rust from blog posts and guessing at the rest.
Training
Hands-on training in Elixir and Phoenix, Rust, and the planning and scoping habits that make AI-assisted delivery work. We run it against your codebase instead of a toy project, because the questions people have are about their own system.
You end up with
- Sessions worked on your own code
- The exercises and notes, kept in your repository
Starting
How an engagement starts
-
A first call
You describe the problem and we ask questions about it. If we are not the right people for it, we say so on that call.
-
Week one
We read the system and sit with your team, then write the problem statement, with the questions nobody has asked yet and what is out of scope.
-
By the end of week two
An RFC for the first piece of work, plus an agreed scope, cadence and review points. From there the work follows our delivery process.
Fit
Who we are not a fit for
A good fit
- Teams that want the whole cycle owned, from the requirement to the numbers after release
- Teams that want AI in their delivery with a person deciding scope, merges and releases
- Systems on Elixir, Rust, Go, TypeScript or Rails, or teams deciding whether to move to one
Not a fit
- Teams buying headcount by the seat
- Fixed-price builds against a spec someone else wrote
- Work with nobody on your side who can make product decisions
- A rewrite started before anyone has read the current system
Questions
Before you get in touch
- Who owns the code?
- You do. The code and IP we write for you under the contract belong to you.
- Do you sign an NDA?
- Yes. We sign your NDA before any code or data is shared with us.
- Where do our code and data go?
- Only into the AI tools you have approved. A person on our side reviews every change before it is merged.
- What time zone do you work in?
- India Standard Time (UTC+5:30), from Pune. The hours we overlap with your team are agreed at the start of an engagement.
- How do we start?
- Describe the problem in a few sentences on the contact page. The first call is about that problem, and the steps above follow from it.
Engagement
How the commercial side works
The default is a monthly retainer for a set number of days, which suits work that runs for a quarter or more and changes shape as it goes. Fixed milestones work for a well-defined piece with a clear finish line, and we will tell you which of the two your work is.
We invoice monthly in USD or INR, and clients outside India pay through Skydo. Everything is remote from Pune.
We do not do unpaid proof-of-concept work.
- Model
- Monthly retainer, or milestone contracts
- Currency
- USD or INR, invoiced monthly
- Ownership
- The code and IP we write for you under the contract are yours
- NDA
- Yours, signed before any code or data is shared
- AI tools
- Your code and data go only into tools you have approved
- Location
- Remote from Pune, India
- Time zone
- IST (UTC+5:30), overlap agreed at the start
- Languages
- Elixir, Rust, Go, TypeScript, Ruby
- Frameworks
- Phoenix, LiveView, React, Angular, Rails, Leptos
- Domains
- Fintech, insurtech, e-commerce, edtech, logistics, warehousing, data platforms
Not sure which of these you need
Describe the problem and we will tell you, including when the answer is that you do not need us.