About
We build software and run the cloud it lives on.
Softlanceo is a software engineering company. We design and build web applications, SaaS platforms, APIs and the internal tools businesses run on — and we own the AWS infrastructure underneath them rather than handing that to someone else.
That second half is the part most engineering companies leave out, and it is the reason we exist in the shape we do.
01/The reasoning
Why one team does both.
The conventional split is an agency for the application and a cloud consultancy for the infrastructure. On paper it looks like specialisation. In practice it puts a contract boundary through the middle of a single system.
The consequences are consistent enough to predict. Architecture gets chosen by people who will never operate it. Running cost is discovered on an invoice instead of decided on a whiteboard. Incidents open with a jurisdictional argument. And handover, when it comes, is a repository and a diagram that stopped being accurate months earlier.
None of that is caused by bad engineers. It is caused by the boundary. So we removed it: the people who design the system operate it, the cost of an architecture is priced while it is still free to change, and there is nobody to hand the problem to at 3am.
It also constrains us, which is the point. We only take on work we can carry on both sides, and we stay small enough to do that properly.
02/Commitments
Four things you can hold us to.
Each one is checkable. If we break any of them, you will know, which is the only kind of commitment worth publishing.
- You talk to the people doing the work
- Every conversation, from the first email onward, is with an engineer who will be on your project. There is no sales layer, and nobody is going to hand you over after you sign.
- You own everything we produce
- Code in your repository, infrastructure in your AWS account, documentation written for someone who was not in the room. Nothing in the stack requires us to stay.
- We tell you what we found, including when it is inconvenient
- If the bill is already about right, if the migration is not worth doing, or if we underestimated something, you hear it from us early rather than reading between the lines of an invoice.
- We do not use support contracts to hold on to clients
- Support is monthly with a notice period both ways, and the handover material exists throughout — not assembled once you give notice.
03/How we are set up
Small, senior, and on both halves.
We would rather describe how the team is shaped than publish headshots and job titles that tell you nothing about who will be on your project.
- Small teams, senior-weighted
- Engagements run with a small number of experienced engineers rather than a large team with a thin layer of seniority on top. Fewer people who understand the whole system beats more people who each hold one part.
- The same people across both halves
- The engineers writing the application also work on the infrastructure it runs on. That is the structural reason the architecture and its cost profile stay connected.
- No handoff after the sale
- Whoever scopes your work is on it. The proposal is written by the people who will have to deliver against it, which tends to make proposals more honest.
- We stay small on purpose
- We take on work we can staff properly. When we cannot, we say so and tell you when we could, rather than accepting it and stretching a team across it.
05/Questions
Softlanceo, asked about.
01Why do you do both software and infrastructure?
Because splitting them is where most of the expensive problems come from. When one team owns the application and another owns what it runs on, the architecture gets decided by whoever cannot see the consequences, and every incident starts with an argument about whose side it is on.
02Do you have case studies?
Not published ones. Most of our work sits inside client products under agreements that do not allow us to describe it, and we would rather show nothing than write a case study vague enough to be permitted. We are happy to talk specifics under NDA.
03How do we know you can do this?
Talk to us about your actual problem and judge the answers. A first conversation with an engineer who has read your code or your AWS account tells you more than a logo wall would.
Judge us on the first reply.
Send us something real — a problem, an AWS account that has grown strange, a product you need built. The answer will tell you more than this page can.