Craftis Field Note

We Didn’t Want to Become Another Consultancy

How our definition of success changed from delivering technology to building engineering capability.

We never set out to become another consultancy.

We set out to solve engineering problems.

Somewhere along the way, our definition of success changed.

Every consultancy promises expertise.

Many promise quality.

Some promise innovation.

Those are all important, but they are also expected. No client hires a consultancy hoping for average engineers or mediocre outcomes.

When we looked back at the projects that had the greatest impact on us, we noticed something unexpected.

The projects we remembered most were not necessarily the largest, the most complex, or the ones that used the newest technology.

They were the ones where the client no longer needed us.

At first, that felt like a strange way to measure success.

After all, why would a consultancy celebrate becoming less essential?

The answer became clearer with every engagement.

Dependency is easy to create.

Capability is much harder.

The Moment Our Thinking Changed

Like many engineering consultancies, we started with a familiar objective: deliver a successful project.

Build the platform.

Automate the deployment.

Improve reliability.

Solve the technical problems.

Those things still matter. They always will.

But as projects came to an end, we found ourselves asking a different question.

What happens after we leave?

Can the engineering team confidently deploy changes?

Do they understand why the platform is designed the way it is?

Can they troubleshoot issues without relying on us?

Will the documentation help the next engineer six months from now?

Those questions became more important than the deployment itself.

Because a platform is not truly successful if only its creators know how it works.

Technology Was Never the Final Product

Over the years, we have worked with different cloud providers, programming languages, deployment pipelines and architectural patterns.

Some technologies evolved.

Others disappeared.

Best practices changed.

The tools were different, but one observation remained remarkably consistent.

The strongest engineering organisations were not defined by the technologies they chose.

They were defined by how well they understood them.

Understanding creates confidence.

Confidence creates independence.

And independence allows engineering teams to continue improving long after a project has finished.

That became the outcome we wanted to leave behind.

Engineering Is About More Than Delivery

There is satisfaction in solving difficult technical problems.

Designing a resilient platform.

Automating a deployment pipeline.

Improving observability.

Reducing operational risk.

These are meaningful engineering achievements.

But they are only part of the job.

Real engineering also means sharing knowledge.

Explaining decisions.

Documenting trade-offs.

Helping teams understand not only what was built, but why it was built that way.

Because every design decision carries context, and context disappears quickly if it is not shared.

We have learned that a platform becomes sustainable when knowledge is distributed rather than concentrated.

Why We Created Craftis

At some point, we realised we did not simply enjoy building platforms.

We enjoyed helping engineering teams become stronger.

That realisation changed how we approached every engagement.

Instead of asking:

How much can we deliver?

We started asking:

What capability can we leave behind?

That shift became the foundation of Craftis.

It is why knowledge transfer is part of every engagement.

It is why we favour simplicity over unnecessary complexity.

It is why we challenge our own assumptions before recommending technology.

And it is why we believe the best consultancy relationships become partnerships built on trust rather than dependency.

What Changed for Us

We stopped measuring success by the amount of software we delivered.

We stopped measuring success by the number of cloud services we deployed.

Instead, we began measuring success by something less visible but far more lasting.

Did the engineering team become stronger?

Could they continue evolving the platform confidently?

Did we leave them better equipped than when we arrived?

If the answer is yes, then we have achieved what we set out to do.

Because, in the end, our goal is not to become indispensable.

It is to leave behind something far more valuable.

Engineering capability.