Two questions come up on nearly every first call, in one form or another. Do you build on your own platform? And could another team take this over later? They are really the same question: if this goes well and then something changes, am I stuck?
The answer is no, and this post explains why, including the part that surprises people: we plan every system for handover, and most of our clients never use the plan.
No platform of our own
Some firms build on a proprietary framework, a low-code platform they resell, or a stack so unusual that only they can staff it. The pitch is speed. The cost shows up in year three, when you want a change the platform does not allow, the license renews at a new price, or the firm is the only one on earth who can maintain what you own.
We build on mainstream, well-supported technology: the major web and mobile frameworks, the major public clouds, standard databases and languages that a competent engineering team anywhere can pick up. The stack is chosen per project, for what the system has to do and for the team who will live with it, and we are not tied to any vendor. We hire for fundamentals and the ability to learn fast, not for one framework, which is why we can make that choice honestly.
The test we use: if this client had to hire a local engineer to maintain the system, could they? If the answer is no, we have chosen wrong.
Everything in your name
The code lives in your repositories. The cloud accounts are yours. The domain, the credentials, the documentation, the backlog: yours. You own the intellectual property outright, in the contract, not as a courtesy. A system you cannot run without us is not finished, and we mean that structurally, not as a slogan.
Built as if someone else will run it
Every system we build is documented as we go, not at the end. Architecture decisions are written down with their reasons. Environments are reproducible. Your people sit in the reviews and see the system take shape. When we finish a project, the closeout includes what a new team would need to pick it up: how it is built, how it is deployed, where the bodies are buried.
We do this on every project, whether or not a handover is planned, for two reasons. The first is that it is simply how well-built software looks; a system only one person understands is a risk regardless of who that person is. The second is that it keeps us honest. A firm that knows the client can leave has to earn the renewal.
Most clients keep us on
Here is the part that surprises people. Having planned for handover on every project, we end up maintaining and managing about seventy percent of what we build. Most of our clients do not have an in-house engineering team, and most never intend to build one. They keep the people who built the system on the other end of the line, through Managed Hosting & Support or a dedicated team, because it is the cheapest way to get the coverage they want.
There is no contradiction. The plan for handover is what makes staying with us a choice rather than a trap. Clients stay because the work is good and the relationship is worth it, not because leaving would be painful. Some do hand over, to an in-house team they grew, or after an acquisition, and the handover goes the way it was planned to go.
What this means when you compare firms
Ask any firm these questions, and listen for hesitation:
- Who owns the code and the IP, and where does it live?
- Is there any component I would have to license from you to keep running?
- Could I hire a local engineer to maintain this, and how would they learn it?
- If we parted ways next year, what would I have, and what would I be missing?
The right answers are: you, in your accounts; no; yes, from the documentation and a handover; everything, nothing. If a firm’s answers are different, understand that you are buying a dependency along with the software, and price it accordingly.
We would rather be kept on because we are good than because you cannot leave. So far, that has worked out for both sides.