Software has to keep working after we leave
LivingTech runs two businesses on one engineering standard. We build and operate Folow, our own enquiry to sale platform. We also build systems inside organisations that already carry production traffic and cannot stop while we work.
- What we build
- Our own products, plus platforms, integrations and applied AI inside client systems.
- How an engagement starts
- From the operational constraint, in the words of the team that lives with it.
- What handover includes
- Runbooks, instrumentation and a walkthrough with the engineers who will own the system. See how the work runs
- Working with us
- We hire slowly and keep the team small, so engineers speak directly to clients. Careers at LivingTech
A product company that also takes on other people's hard problems.
Folow is the clearest example of how we build. It is a real product, operated by us, carrying real data. Client work runs against the same standard, which means the questions we get asked internally are the questions a client asks us: what happens at 2am, what does this cost to change, who owns it in year three.
The two activities keep each other honest. Products expose us to operating constraints we would otherwise only read about. Client work keeps the products from drifting into features nobody outside the building needs.
We are based in India and work with organisations across several markets. We are comfortable saying a requirement is unnecessary, and comfortable inheriting half a system we did not design.
Six positions that have cost us work.
Each one has cost us a project or a fee at some point, which is the only evidence we have that they are real rather than decorative.
The domain comes before the stack
We cannot pick a database until we know what the business does with the data, so the first conversations are about the operation rather than the architecture.
A rule is better than a model when a rule works
Plenty of operational decisions are deterministic and should stay that way. Adding inference to remove a decision is cost without a matching benefit.
Maintainability is a feature
We plan for the second and third year of a system, not only for the delivery date. Anything expensive to change will eventually be frozen by whoever inherits it.
Security belongs in the data model
Least privilege, encryption and audit trails are decisions about shape, not a checklist applied at the end of a build.
Boring technology in the critical path
We spend novelty on the product and keep the plumbing well understood. If a dependable tool already does the job, that is the choice.
The uncomfortable point gets raised early
A requirement that will not hold, a timeline that assumes otherwise, a plan that needs rewriting. Hearing it in week two costs a conversation. Hearing it in month six costs a rewrite.
The sequence we keep arriving at.
Not a methodology we apply identically. It is the shape that keeps a project honest and the code changeable.
Understand
The constraint, described by the people who currently absorb it.
Model
Entities, states and rules agreed before any schema is frozen.
Design
Interface flows and error states designed against that model.
Build
Thin vertical slices, each usable on its own and each reversible.
Operate
Instrumented in production, and supported after the handover.
Boundaries instead of cleverness
Modules separated by contract, dependencies visible, and the full cost of a change understood before it starts. Code that needs a genius to maintain is code nobody maintains.
Problems rather than feature lists
Success gets defined before scope does, and removing a requirement is as normal as adding one. A smaller product that works beats a larger one that is nearly ready.
Autonomy has to be earned
Every agent gets a defined scope, a stopping condition and a named person accountable for the result. Anything wider waits until the narrow version has been reliable for a while.
Assume the intern is careless
Least privilege, encryption everywhere and a complete audit trail. A design that depends on everyone being careful most of the time is not a control.
Delivery is the easy part.
The value of an engineering engagement is created in the years of operation that follow it, which changes what we think handover means.
Handover with your engineers in the room
Documentation, runbooks and a walkthrough with the people who will own it. If they cannot maintain it, we have not finished.
Support scoped to what you rely on
Ongoing support built around the systems that matter to you, with a named escalation path instead of a ticket queue.
Roadmap opinions you did not ask for
We will tell you when the proposed next feature is the wrong next feature. That argument is part of what the engagement buys.
Where to go next from here.
These are the pages that answer the questions we are asked most often in a first conversation.
How the work is delivered
Six capabilities that combine into most engagements.
- AI and automation Applied AI with a person accountable for the outcome.
- Software engineering Backend, frontend and the testing around business rules.
- Cloud and DevOps Infrastructure, delivery pipelines and observability.
- Legacy modernisation Replacing systems that cannot be switched off.
- API and integration Connecting systems that were never designed to speak.
Where the operating model is specific
The same architecture behaves differently in each sector.
- Healthcare Records, consent and scheduling under audit.
- Education Academic years, cohorts and campus operations.
- Retail Store operations, stock and omnichannel enquiries.
- Automobile Dealer networks, service booking and parts.
- Real estate Units, tenancies and maintenance requests.
The rest of the site
Background on how we work and where we publish thinking.
- Solution patterns The engineering shapes we build repeatedly.
- Insights Working notes on applied AI and architecture.
- Folow Our own platform, described in detail.
- Careers How hiring works when there is no vacancy listed.
- Contact Every enquiry is read by an engineer.
Tell us the constraint you are carrying.
Start with the operational problem rather than a brief. We will tell you what we would do first, what we would deliberately avoid, and whether we are the right fit.