Fromcode has built software for clients since 2011. Today it is me, Kristian, and I lead every project myself.
People sometimes ask, politely, whether that is a limitation. Sometimes it is, and I would rather say so plainly than let you find out halfway through a project. More often it is the point. This article is about both: what working with me directly gives you, where its limits are, how I bring in other people when a project needs them, and how a project is set up so that it never depends on me being around.
The problem with hand-offs
In a larger company, the person who understands your problem and the person who writes the code are usually different people. Between them there is often a salesperson, a project manager, a ticket system and a specification. Each of those steps exists for good reasons, and each of them loses something: a detail that seemed obvious, the reason behind a decision, the thing you mentioned once on a call and nobody wrote down.
A lot of software that disappoints its owners does not fail because of bad code. It fails because what was built is not quite what was meant, and nobody noticed until it was finished. The distance between the person who understood the problem and the person who built the solution is where that happens.
Working with me, that distance does not exist. The person you explain the problem to designs the solution, writes the code, deploys it and answers when something goes wrong.
What that gives you
- Answers from the person who decided. When you ask why something works the way it does, you get the reason, not a promise to find out.
- Decisions made with the whole picture. The trade-off between a quick fix and a proper one is made by someone who knows both the code and your business.
- One person answerable for the whole result, including the parts someone else helped with. There is nobody else to point at, and I do not look for one.
- A written answer to your messages within two working days.
- Continuity. The person who built the first version is the person who changes it a year later, and remembers why it was built that way.
What it cannot give you
One person has limits, and pretending otherwise helps nobody:
- There is a limit to how many projects I can lead at the same time. That is why a project with me has a clear first step and a clear scope, rather than an open-ended team on call.
- Some work needs a different craft, and some fields have specialists with years of experience I do not have.
- A project that needs several people working on it full-time, for a long time, is not a project I should lead alone. If that is your project, the honest answer may be that I am not the right choice, and I will tell you that at the start rather than after a proposal.
When I bring someone in
When a project needs a craft I do not have, visual design, careful testing on many devices, hardware, or a specialist field, I bring in someone for that part. Three rules apply every time:
- You know who they are before they start, and what they are responsible for.
- I review what they deliver before it reaches you.
- I stay answerable for the whole result. Bringing someone in does not move the responsibility to them.
That is different from subcontracting a project away. The specialist works on a part; the project stays mine.
Handing it over
A project that depends on one person has to be ready to outlive that person’s involvement: because the project ends, because you bring the work in-house, because you choose another supplier, or because something happens to me. So the things you need to carry on without me are part of the work from the start, not a task at the end:
- The code is in a repository you have access to, with its full history.
- The accounts that matter, hosting, domain, payment provider, e-mail service, are in your name.
- How the system is built and deployed is written down, and can be repeated by someone else.
- The secrets it needs are listed, so they can be changed if someone leaves.
- Backups exist, and restoring one has been tried.
- There are short notes on how the system is put together and where the unusual parts are.
Whoever works on it next should be able to start from that, without needing me in the room. It is also a good test of the work itself: a system that cannot be handed over is a system nobody fully understands, including the person who built it.
Whether you work with me or with someone else, these questions tell you most of what you need to know about a small supplier:
- Who will actually write the code?
- Whose name are the accounts, the domain and the repository in?
- What happens if you are ill for two weeks?
- How would another developer take this over, and what would they receive?
- What will you tell me when you do not know something?
A good supplier answers all five without hesitating, and does not mind being asked.
Want to talk to the person who would build it?
Write a few lines about the project.