Your development partner should have an opinion

The initial vibe coding buzz has started to quieten down as process and proper architecture take over once again, as they always do. We’re getting a clearer idea of the capabilities, strengths and weaknesses of AI and LLMs. With that, a new pattern is emerging in what we expect from development and our development partners.

Now that we know these tools can properly increase output, the bottleneck, of course, isn’t just producing code. More than ever, it’s what goes into it: the quality of the thinking, the decisions, and the code itself.

This comes back to the age-old question of what makes an actual development partner. You need someone who understands your business well enough to cut through the noise of what’s important and what isn’t, and who will challenge you when they need to. Someone who says yes to your every whim isn’t doing that job.

But is that value really value?

This can creep into all sorts of parts of a build: an interesting display, getting creative with interactivity, pulling reports or creating dashboards. These things are quicker to put together now, and they’re often more fun for the development partner to work on. You can get something working quickly and show the client value. But is that value really value?

A new dashboard might just be more noise. Another place for an administrator or marketing manager to look, and another decision about which stats deserve their attention. Or we’re setting up a display: do we want a list or a calendar? Well, why not have both? It’s doable, but are we making things more useful or just adding more fat?

These are only a couple of examples, but we’re going to see this throughout the industry. When your options are practically endless, picking the right one matters more than ever.

Get it into people’s hands

The approach I always take is to get it into people’s hands and test it before adding too many bells and whistles. Something you want isn’t necessarily something your customers want. Depending on the demographic you’re targeting, those additions might just create confusion.

More options, more tabs, more decisions for a customer to make usually means more friction. We want people to get to what they actually came to the site or application for with as few unnecessary steps as possible. Seeing how they use it gives us a much better idea of what deserves to be added.

We follow service design principles and take a lean approach: don’t over-engineer a feature, but don’t under-engineer it either. That’s where we’re aiming for value. Over-engineer it and you risk the confusion we’ve already talked about. Under-engineer it and people can’t get what they need from it.

Getting that balance right comes down to reading and reacting. Put it into people’s hands, get information, test what’s working and go again. We can work in those cycles, making decisions based on what we learn. To me, that’s what working in an agile way should actually mean.

Honesty, pushback and speed

So, coming back to choosing a development partner: what do you actually want out of that relationship?

First and foremost, honesty. Honest about their capabilities and honest about what’s possible. You don’t want someone to sell you the dream and then leave you high and dry. If you can get into a conversation with the person who will actually do the work, you can get a much clearer picture of what’s involved and what they can deliver.

Second, you want someone who will push back. Bring your ideas, but expect guidance and recommendations in return. That doesn’t have to mean an outright no. It might be advice, an alternative, or a different way of approaching the problem that works better for your business. It needs to work for them too. At the end of the day, it’s a symbiotic relationship.

Third, you should expect speed. If someone tells you it’ll be six months before you get anything into people’s hands, I’d be looking elsewhere. That doesn’t necessarily mean the work will be cheaper, but the tools we now have should translate into faster delivery, faster feedback and faster decisions.

Start with the conversation

If you’re looking to commission a build, I’d start by asking what your actual objective is. What’s the minimum lovable product we’re trying to get into people’s hands? What’s your expected timeline? What have you been burnt by in the past, and why are you looking to do this now? Those answers give us something useful to scope and explore together.

Look for someone who’s willing to sit down and talk through those requirements. Someone who wants to understand what you’re trying to achieve before promising to build everything you’ve asked for. In this day and age, with so much more within reach, a yes-man is the worst possible outcome.