Product Development
Build the product. Keep the keys.
Design, engineering and QA in one team that works inside yours. You see working software every week, and the code is in your accounts from the first commit.
Kandu Health reached a soft MVP in 6 months and a full mobile MVP in about 12.
What you can hold us to
Six promises you can check us on, before and after you sign.
Meet your engineers firstThe people you interview are the people who build.The worry“A senior sells the project, a junior builds it.”
Before signing you meet the lead engineer and anyone else on the team, and you can decline. The team named in the proposal is the team on the repo.
“The engineer assigned to the project was very proficient, and jelled with the team very quickly. He started delivering value for us after only a few weeks of on-boarding.”Torin TaerumasdSr Director Product Development, TempusWhat if an engineer leaves?
We tell you first, and you meet the replacement before they start. The two overlap for a handover, and we pay for it.
Your keys from day oneRepository, cloud and store accounts live in your name.The worry“The vendor holds the code and the accounts.”
You create the GitHub organisation, cloud account and app store accounts, or we create them in your name on day one, and invite us in.
We are the builders. You own what we build.
Can you start in our existing accounts?
Yes, that is the default.
Something to click every weekA working demo every week, not a status report.The worry“No working demo until the end.”
Every week ends with a demo on a staging environment you can open yourself.
“Kandu Health reached a soft MVP in 6 months and a full mobile MVP in about 12.”Kirsten CarrollCEO, Kandu HealthWhat if a week has nothing to show?
Then we say so, and show the tickets that moved and why.
We say noIf a feature is not worth building yet, you hear it before you pay for it.The worry“Agencies say yes to every feature and bill for it.”
Discovery ends with a list of what we recommend not building in the first version, and why.
Why not build it with AI?
We do, every day. See what stayed expensive.
Easy to replaceDocs and setup good enough for another team to take over.The worry“We will depend on them forever.”
Every milestone includes:
- A README that runs the project from the repo on a fresh machine
- Deployment, documented
- A secrets inventory
- An architecture note
You can have an outside reviewer check it any time.
Estimates you can open upAsk, and any estimate breaks down into tickets, each with a size.The worry“Hourly billing rewards dragging. Fixed price rewards rushing.”
An estimate is a tree: feature, tickets under it, a size on each ticket, assumptions listed. Change requests get the same treatment before work starts.
Show me oneA sample estimate for one small feature.
Feature: sign-in and accounts
Assumptions:
- Email and password only, no social sign-in in this version
- Three fixed roles, no custom permissions
Why not just build it with AI?
AI writes the code. Someone still has to own the product.
We build with AI every day, using Claude, Codex and Gemini. It made writing code cheap. Three things stayed expensive.
01 Deciding what to build
A well-built wrong feature is the most common way to waste money.
02 Making it hold
Data model, security, tests and releases that survive real users.
What breaks first in AI-built prototypes
- Auth and permissions
- Data migrations
- Payment edge cases
- Anything concurrent
03 Keeping it running
The fix at 2am, the upgrade nobody planned, the integration that changed.
How we work
Four stages. You keep everything built at the end of each one.
01 DiscoverWe agree the smallest version worth shipping, and what to leave out.
At the end you have:
- A scope for the first version
- An estimate you can open up
- The list of what we recommend not building yet
02 BuildDesign, engineering and QA in weekly cycles. Every week ends with something you can click.
At the end you have:
- Working software on a staging environment
- Code in your repository, reviewed and tested
- A README that runs it on a fresh machine
03 LaunchRelease, app stores, monitoring. The boring parts that decide whether launch day goes well.
At the end you have:
- The product live, in your accounts
- Monitoring and alerts
- Documented deploy and rollback steps
04 EvolveReal users change the plan. We keep shipping with you, or hand over cleanly. Our average client stays 3.5 years.
At the end you have:
- A product that keeps improving on real usage
- Or a handover another team can pick up
Proof
Our average client has worked with us for 3.5 years.
Kandu HealthKirsten CarrollCEO, Kandu Health
“The Galliot team has been amazing to work with from all aspects – engineering talent, cost, reliability, and communication. They’ve understood our challenges and needs and we’ve been able to smoothly integrate their team and work into our own internal business. They’ve had great foresight in ensuring we’re building the right thing at the right time, and not over- or under-engineering.”
Clarus DesignsRachel HaleyCEO, Clarus Designs
“Working with the Galliot team has been one of the best professional experiences for Clarus Designs. Galliot embeds themselves so they are an extension of your team; allowing you to maintain focus on high-level priorities without the burden over management and execution. Galliot offers best in class strategy, design, and development structure; would highly recommend”
TrulyErol TokerCEO, Truly
“They are a terrific business partner to work with and the quality of their work is outstanding. We’re excited to continue working with them”
FAQ
Who will we work with?
Where is your team, and when are they online?
How will we communicate day to day?
What happens when we change our mind mid-build?
Can you start from our existing code, or an AI-built prototype?
How do you price?
Whichever it is, you can ask for any estimate broken into tickets with a size on each.
Can we talk to past clients?
Have you built for healthcare and handled patient data?
Who fixes bugs after launch?
The usual path: we build the product, maintain it, and keep growing it beside you, at the pace you need. Fixes are part of that.
What if we want to take it in-house?
Show us what you are building
A few lines or a rough prototype is enough. An engineer replies.