Choosing the right technical partner: why you can't have all three sides of the triangle

How to choose a technical partner who understands code, commercials and compromise, and why chasing cost, speed and quality all at once backfires.

Updated 8 min read

A good technical partner tells you early which two of cost, speed and quality your project can have, and helps you choose. Technical skill is the starting point. What separates partners is whether they understand your business well enough to make that trade-off with you, and to say so when a plan won’t fit.

Most projects begin with a version of the same promise:

It’ll be quick, high quality and good value.

That covers all three points of the project triangle. You rarely get all three at once, and the partner you choose decides which two you’re really buying.

This guide looks at how the triangle plays out in real projects, why technical skill alone isn’t enough, and what to ask before you commit.

The myth of having it all

The Triangle Is Simple

Cost Speed Quality

The Tension

Hover or tap to explore

The trade-offs

  • Cheap and fast usually costs some quality
  • Fast and high quality usually means a higher day rate or a bigger team
  • Cheap and high quality usually means accepting a slower, phased roadmap

Most problems start when everyone acts as if the trade-off doesn’t exist.

Stakeholders are sold a “no compromise” project. Developers say yes because they want the work. Nobody draws the triangle on a whiteboard and asks:

If we had to lean towards two of these, which two matter most to the business this year?

Leaving that question unasked leads to half-built features, awkward conversations and broken working relationships. A good technical partner asks it early.


Technical skill isn’t enough on its own

It’s tempting to look for a partner who’s simply brilliant with code: someone who knows Laravel, Shopify and WordPress, has strong DevOps skills, and can talk at length about performance scores and Core Web Vitals.

All of that matters. A technical mind looks for the elegant solution. A commercial mind looks at outcomes, timelines and how the organisation works. When you’re spending real budget, you need both in the room.

A technically strong but commercially inexperienced partner might:

  • Build early phases for hypothetical future needs
  • Suggest a stack too new for your internal team to support long term
  • Underestimate what change costs inside a busy organisation
  • Miss a campaign deadline while aiming for perfect architecture

On paper you get tested, documented code. In practice the project may drift, cost more, or miss the window where it was most valuable.


What a commercially aware technical partner looks like

Good code is the baseline. A strong partner also turns your commercial position into technical decisions, and explains the trade-offs in plain terms.

That looks like:

  • Asking about margin as well as modules: how the site or app supports revenue, efficiency or lead quality
  • Starting with constraints: budget, capacity, approvals, regulation and seasonality
  • Designing small, shippable steps that go live and prove their value
  • Saying “no” politely when a feature or deadline doesn’t fit the triangle

A commercially aware developer or small team will still care about TTFB and Lighthouse. They’ll also care about:

  • How easily your team can update content without external help
  • What extra integrations cost in support, training and future change
  • What bespoke features cost over the years, compared with stable plugins or apps

They’re comfortable talking to marketing, operations and finance. They can explain to a non-technical director why a cheap shortcut now might cost more later, without jargon or alarm.

3D render representing the triangle of cost, speed and quality

Understanding your own triangle

Before you choose a partner, be honest about your own priorities.

For example:

  • A campaign date that can’t move
  • A fixed annual budget that can’t stretch
  • A history of painful rebuilds, so stability matters more than novelty

Each of these pushes you toward one side of the triangle.

A useful exercise at briefing stage:

  1. Draw the triangle: cost, speed, quality.
  2. Mark three points on it: where you are now, where leadership thinks you are, and where you’re comfortable being.

The gap between where you are and where leadership thinks you are is where projects go wrong.

A commercially aware partner will start this conversation early. They may even turn the project down if expectations don’t line up, which is a good sign.


The risk of just hiring a developer

Many businesses reach a point where they decide to hire a developer and leave it there. On paper it looks efficient: direct access, no agency overhead, and someone who can build what you need.

The risk is in the gaps around that role:

  • Who is prioritising work based on commercial outcomes?
  • Who is shaping requirements into clear, buildable specifications?
  • Who is challenging assumptions about return on investment?
  • Who is considering long-term maintainability as systems grow?

If the answer to each is “the developer”, you’re asking one person to hold three roles: engineer, product manager and digital strategist. That’s a lot to ask of anyone.

A strong technical partner works well with in-house developers and marketers. They know when to lead and when to support, and they don’t try to be everything.


Context matters more than capacity

Large agencies offer capacity: more roles, wider coverage and a polished process. Freelancers and small studios offer depth: you work directly with the person doing the work.

Neither is right for every project. The question to ask is:

Who is most likely to understand the context of our business well enough to make smart trade-offs when we’re not in the room?

A partner with context will:

  • Understand how your pricing works
  • Know how your sales cycle works in practice
  • Recognise which stakeholders shape decisions and why
  • Spot where a small change has large knock-on effects

That context leads to decisions that look technical but rest on commercial reasons. For example: a simpler Shopify checkout customisation, so future upgrades go smoothly. A Timber-based WordPress build in place of a quick theme edit, because later changes cost less. A phased Laravel build, so other teams can start their integration work while the interface is still being finished.


Signs you have found the right partner

You’ll never have perfect information, but some signs are worth watching for.

They push back, calmly

A good partner doesn’t agree to everything. They challenge unrealistic deadlines, vague feature creep and decisions that work against long-term goals. They do it without friction, by showing you the trade-offs and letting you choose.

They speak the language of outcomes

They talk about better leads, less admin and shorter sales cycles. Tools and frameworks help get there. They still enjoy the technical detail, and they know what it’s for.

They plan in phases

A good technical partner presents a phased roadmap:

  • Phase 1: launch something lean that reflects your brand
  • Phase 2: strengthen the infrastructure, improve conversion and refine how content is managed
  • Phase 3: add advanced features once the foundations have proved their worth

They expect the first version to need changes, and they design for them.

3D render representing delivery in phases

Practical questions to ask before you commit

Rather than “what stack do you use?”, ask questions that show how a partner thinks:

  • “Tell us about a project that ran into trouble, and what you changed afterwards."
  • "How do you approach situations where a client wants all three sides of the triangle?"
  • "When do you recommend building bespoke, and when do you lean on existing plugins or apps?"
  • "How do you decide what to cut if a deadline cannot move?"
  • "What happens after launch, and how do you support teams who are not technical?”

Listen less for the tools they name. Listen for honesty about trade-offs, ease in talking about cost and value, and whether they measure success by your numbers or by their portfolio.

Shopify has its own hiring traps: bloated themes, stacked app subscriptions and badge-led marketing. How to hire a Shopify developer covers the questions to ask and the red flags.


Making the choice

There’ll always be someone cheaper, or someone who promises more in less time. The right partner is often cautious at the start: curious about your business model, clear about what your triangle allows, and open about the trade-offs.

Code is half of what they work with. The rest sits in board meetings, marketing plans, support queues and the day-to-day detail of running the business. Look for technical skill backed by commercial judgement. The triangle won’t go away, but you’ll make the trade-off knowingly.

Working with me

I take on WordPress, Shopify and Laravel projects as a single developer: you brief me, and I write the code.

Published , updated .

Part 2 of The Long Game.

Related posts