Software engineering
The first version is the cheap part.
Expensive software is not what it costs to build. It is what it costs to change afterwards, and almost every project is priced as if those were the same thing.
The problem
Projects do not fail for lack of code.
They fail because two years later nobody knows why a decision was made. The code is right there, readable, and still not open to discussion: you cannot revisit a choice whose reasoning was never recorded.
Then every change becomes archaeology, deadlines inflate with no visible cause, and the easy conclusion is that the team is slow. It is not. It is deciding again what had already been decided.
The difference
Producing code and doing engineering are not the same profession.
The distinction shows up in concrete things:
- Production delivers what was asked. Engineering asks what the request is trying to solve, and sometimes the scope shrinks
- Production measures delivery by features finished. Engineering measures by features still standing six months later
- Production treats operation as a later phase. Engineering treats it as a requirement with a deadline
- Production records what was done. Engineering records why, and what was discarded along the way
- Production grows by adding people. Engineering grows by reducing what has to be coordinated
Seniority shows in what does NOT get built. It is the part of the work no hourly rate can bill, and the part that saves the most.
How we work
What we do that changes the cost of changing.
None of this is proprietary methodology. It is what can be verified afterwards:
- 01Architecture decisions are recorded: what was chosen, against what, and what would change our mind
- 02Failure modes are named before they exist, and turned into tests
- 03The system says when it is unhealthy, instead of waiting for someone to complain
- 04External dependencies sit behind a boundary you can point at
- 05Whoever builds it operates it. Delivery without operation is a transfer of debt
These five cost time in the first version and pay back on every change after it. That trade is what the word engineering describes.
New product, API, backend, app. Built to last after we leave.
The list below is what comes out of here. What differs from a software factory is not what we build: it is who answers for the architecture, and what happens to the system in its third year.
Digital product from scratch
From the first usable version to continuous operation. Discovery, architecture, build and what sustains it afterwards, with the same people from start to finish.
When the idea has to exist in production, not in a prototype
API and integration
APIs other teams consume, and integration between systems never meant to talk. Versioned contract, errors that say what happened, and reconciliation across both ends.
When two systems have to agree on the same number
Backend and services
Cloud services that absorb peaks without manual provisioning, with infrastructure as code, observability and cost proportional to real use.
When volume grows and cost grows faster
App and web app
An interface that works on the device your audience actually has, poor network included. We have built apps that run offline and sync when the connection returns.
When the usage happens away from a desk
Legacy modernisation
Changing the engine with the car moving: operations do not stop, and the old system leaves in parts, each one checked at the destination before the next.
When a full rewrite is the answer that already failed once
Data and the decision layer
The path from event to decision: capture, model, and the automatic action at the end. With the dashboard number matching the source, which is the part usually missing.
When the board does not trust its own report
If what you need is not on this list, the thirty-minute conversation settles it faster than writing a scope document would.
Projects do not fail for lack of code.
They fail on a decision nobody wrote down, and that six months later nobody can reconstruct.
The decision
When it makes sense to call us.
It makes sense when
- The system is critical to the operation and failure has a cost you can name
- There is a team, and it is stuck in maintenance instead of moving forward
- The platform has to last years and pass through several hands
- There was an attempt that did not hold, and nobody knows exactly why
It does not when
- The goal is to validate a hypothesis fast and throw it away
- The problem is a product problem and has not become a technical one yet
- The expectation is software factory pricing with engineering accountability
In the first two cases the honest answer is usually someone cheaper than us. We say that in the first conversation, not the third.
What people ask in the first conversation
- What does hiring a software engineering company cost?
- It depends on what is being bought, and the more useful question is what its absence costs today. Fixed scope contracts usually end up more expensive in total, because every change becomes a change order and every estimate carries padding against risk. We work with contracted capacity and revisited scope, which makes cost predictable without pretending scope is.
- How long does it take?
- The first thing in production usually takes weeks, and that is deliberate: a system that only appears at the end hides what was wrong until it is expensive to fix. What takes months is the operation becoming stable under real load, a phase that rarely makes it into a schedule and always happens.
- We already have a team. Do you replace it or add to it?
- We add, and the best setup is the one where your team stays owner of the product. We come in where capacity or specific seniority is missing, and the architecture reference is agreed, not imposed. Replacing an internal team rarely solves anything: the knowledge lost costs more than the capacity gained.
- What stack do you work with?
- The one the operation already has, when it holds up. We mainly run TypeScript, Python, PHP with Drupal, and AWS serverless; but changing stack is the most expensive decision in a project and is almost never the cause of the problem. When we do recommend changing, the reason and the cost of changing come in the same sentence.
- Is the code ours?
- All of it, including infrastructure as code and the decision records. We work in your repository and your cloud account whenever possible. Engineering that only works while the supplier is present is not a delivery, it is a dependency.
A short timeline is not a promise here. It is a record.
- 104
- matches with real-time scoring
- 38
- days from first commit to first QR in production
- 203
- profiles with classified risk and automatic intervention
Figures from the group’s own ventures, built and operated by Code and Soul. We can name them because they are ours.
Where this has run
The offer above has proof, and the proof has an address.
Tell us what needs to be built.
A new product, a system that already exists and has to take more load, or a technical decision nobody inside can make alone.
Engineering is not decoration. It is direction.