A small studio for difficult software.
Kalky Labs is an independent AI and software engineering studio. We take a small number of engagements at a time and give each one senior attention from the first conversation to the handover.
Engineering studio, not an agency.
We build custom software for other businesses, with a specialism in AI systems: agents, agentic workflows, retrieval and document intelligence. Around that specialism sits ordinary, careful product engineering — APIs, data models, interfaces, infrastructure — because that is what determines whether an AI feature survives contact with real users.
Being small is a deliberate constraint rather than a stage we are trying to grow out of. It means we can turn down work that is not a fit, say when something is not working, and keep the people who scoped a project on it until it ships.
It also means we are honest about capacity. If we cannot do your project justice in the timeframe you need, we will tell you rather than take it on.
The habits that make the difference.
None of these are novel. They are the practices that separate a system which demonstrates well from one that is still working in six months, and we apply them from the first commit rather than after the first incident.
- Evaluation before iteration
- A fixture set exists before prompts are tuned, so changes can be judged.
- Traces from day one
- Every run records what it saw and what it did. Debugging is not retrofitted.
- Deterministic guardrails
- Limits, permissions and validation live in tested code, outside the model.
- Boring infrastructure
- Queues, idempotency keys, timeouts, backoff. The parts that decide whether it holds.
- Accessibility as a default
- Semantics, keyboard paths and contrast are part of the component, not a later audit.
- Documented handover
- A codebase someone else can take over is the measure of a finished project.
How a project actually runs.
- Discovery first, always
- Every engagement opens with a short, paid discovery. We would rather tell you in week one that the problem needs a database migration and not an agent than find out in month three.
- You talk to the builders
- The people in your calls write the code. There is no account layer translating a decision into a ticket into a misunderstanding.
- Working software over status
- Progress is demonstrated by something you can use. Written notes accompany each increment, but a document is never the deliverable on its own.
- We will say when we are wrong
- If an approach is not working, you will hear it from us early, with what we propose instead. That is more useful than a green status that goes red at the deadline.
Who you will work with.
Founder profiles · pending
Names, roles and short biographies will appear here once they are finalised. This space is reserved rather than filled, because a studio that invents its own team page is not a studio worth hiring.
Have something difficult in mind?
We like ambitious problems — the ones with awkward constraints, messy data and a real cost attached to getting them wrong. Tell us what you are building and what makes it hard.
- Good fit
- A real workflow with real constraints, an internal owner who can make decisions, and a problem where being wrong actually matters.
- Less good fit
- A chatbot with no defined job, a fixed-scope rebuild of something that already works, or a project that needs to look finished before it is understood.