About TELTH · Product engineering since 2008
An idea that is vivid in someone's head is rarely clear anywhere else. Finding its shape is the part we are good at, and the part that decides whether anything built afterwards is worth using. We have been doing it since 2008.
The diagram shows the shape a typical build takes. People use an app and a web front end. Both talk to a single API. The API sits above the data store, the background jobs and the integrations with systems outside the business.
In our own words
TELTH is a product engineering team of designers, developers and testers who build bespoke software. Since 2008 we have shipped custom systems, mobile apps and the ordinary business tools a company actually runs on, for founders, product leaders and in house teams who need something that fits the way they work rather than the way a product decided they should.
Most of what reaches us starts as an idea that is vivid in someone's head and shapeless everywhere else. The part we love is sitting with that idea until its shape becomes clear, reshaping it into something practical, usable and true to the real world, then building it so it survives real users.
We work from three offices, in India, the mid west of the United States and the United Kingdom, which covers most of the working day between them. A question asked at the end of one day has an answer waiting at the start of the next, and nothing that breaks sits unattended overnight.
What we build
Every engagement is built to your business and then delivered through a controlled process. Project managers, designers, developers and testers, with you or from our development centre.
How the first hundred days go
A first build runs to a plan written before anyone opens an editor. Weekly releases from day thirty six, so you are never waiting to see it.
What we learned to see
The hard part was never the code. It was the seeing, and each of these took a few years to learn properly.
TELTH started in the American mid west, and our first clients did not need the thing they asked for. They needed the thing behind it, and finding it meant sitting in their office and watching how the work actually got done.
We have started every project the same way since.
People used what we built standing up, one handed, between two other tasks, often with no signal. That is a different design problem to the one we had been solving, and it made us slower and more careful about what a screen is allowed to ask for.
Fewer taps, fewer fields, nothing that fails when the network does.
India, the American mid west and the UK were not an outsourcing arrangement. Three overlapping working days meant a question asked at the end of one had an answer waiting at the start of the next, and nothing broken sat unattended overnight.
It is the reason we can promise support and mean it.
Anyone can deliver a first project. Whether a client comes back with the next one is the only honest measure of whether we understood their business, and it is a slower and more useful thing to be judged on.
We started organising ourselves around the returning half of the work.
Founders are not really buying engineering hours. They are trying to find out when something real will be in front of users, so we started saying it plainly and committing to a hundred days from a signed plan to a live MVP.
It changed who calls us and it changed how carefully we scope.
A great deal of the first draft is written by tooling now, and that is fine. It has not made the understanding any quicker, and understanding is still the part clients are actually paying for.
Current tools, current decade, same first question.
The stack
We have shipped on all of it, and left most of it behind. What follows is what we started with, and what it became.
the stack we started on
Still running
What we believe
Software that gets discussed is usually software that is getting in the way. We are trying to build the other kind, the sort that becomes part of how a day works and then stops being noticed.
Understanding the day a system has to fit into takes longer than building it and decides whether anyone keeps using it. That work is not billable in an obvious way and we do it anyway, because everything after it depends on getting it right.
Launch is the point where you find out what you missed. We stay past it, which is why systems we wrote more than a decade ago are still maintained and still doing their job.
Where we are
The largest team. Build, test, release, and the overnight watch on everything running in the UK and the US.
Where most European work starts, and where the shape of it gets worked out.
Where it all started in 2008. North American clients, in the same working day as the people using the software.
India opens the day, the UK picks it up five and a half hours later, and the mid west of the United States carries it another six. Work handed on at the end of one of those days is waiting at the start of the next.
Next step
If it is still shapeless, that is the part we like. Send the idea, the half finished repository or the system nobody wants to touch any more, and a senior engineer will come back to you within a working day.