Most developers are often focused on how a solution will be built, while sales teams are typically focused on understanding what the client needs. A technical solutions architect has to hold both perspectives at once, making it a demanding role within a software team, and one that only works alongside the other disciplines.

There’s a role in software that people outside the industry rarely hear about, yet it can have a significant influence on whether a project ultimately succeeds or fails. It sits in the gap between what a client says they want and what a development team actually builds.

The people who fill it speak two languages: code and client.

To understand what the job really involves, we sat down with Christoff Labuschagne, one of the technical solutions architects at Kohde, to talk through the mindset and daily work involved in the role. Christoff also works closely with Kohde's business development and sales teams, giving him a perspective across both the technical and commercial sides of a project.

From "How does this work?" to "What does this person need?"

Most solutions architects start out as developers. The move into the role tends to happen when the interesting question stops being how an application works and becomes what the business actually needs it to do.

“The biggest shift for me has been moving from ‘How does this application work?’ to ‘What does this person or business need to achieve, and how can technology help them get there?’”

That shift, it turns out, is the whole job.

So What Does a Technical Solutions Architect Actually Do?

The clearest way to explain it is with a house.

“Imagine someone wants to build a house, but they don’t know what materials to use, how the rooms should connect, or whether the foundation will support what they want to do in future. My role is to understand what they need, design the right structure, and make sure the people building it have a clear plan.”

A developer focuses on building the individual parts. A project manager keeps timelines and budgets on track. The architect connects the worlds: client, business need, technology and delivery. The work usually starts early, in the first conversations with a client who has a goal but not yet a solution.

“At the end of the day, my focus is making sure we deliver the right solution, not just a working solution.”

The Part Where the Role Sells (Without Selling)

Here’s the thing about deeply technical work: plenty of brilliant people freeze the moment they have to sell it. A solutions architect can’t afford to, not because the role is about salesmanship, but because a solution that can’t be explained never gets built.

“You can have the best technical solution in the room, but if you can’t explain why it matters, or why it solves the problem, then it won’t land with the client.”

Done well, it doesn’t feel like selling at all.

“When the problem is understood properly and the technology is aligned to it, the engagement and the solution almost sell themselves.”

It also means being honest rather than impressive: flagging what’s complex or risky upfront instead of making it sound easy to win the work. Clients can tell the difference, and it’s what makes them feel their investment is being handled responsibly.

Why the Role Builds Trust

A technical solutions architect earns a client’s confidence by standing credibly in two rooms at once. Years of hands-on development mean the architect isn’t speaking from theory: they know what it takes to execute, where the risks hide, and what the delivery team will have to weigh up. Then they translate all of that back to the business in plain terms.

“The client’s technical team feels confident that we understand the execution, and the business team feels confident that we understand the outcome they need. When both sides feel that confidence, the client starts to trust you as a partner rather than just a supplier.”

It’s also the role that has to referee the moments when the technically perfect answer and the commercially sensible one pull apart. Rather than cut corners or over-engineer, the usual answer is a phased approach: solve the immediate problem properly, but design it so the client can grow into the bigger solution over time.

Under Pressure: The Role at Its Hardest

The real test comes when a project is in trouble. Picture one that’s effectively over: the contract winding down, the relationship soured, delivery behind schedule, coordination broken.

In that situation, the instinct to talk your way back into a client’s confidence is the wrong one. The job is to deliver something useful, fast: get a workable first solution into the client’s hands, explain every decision clearly, and let execution do the talking. On one project our team described, that approach turned a client heading for the exit into one who extended for another three years, at nearly double the original scope.

“Trust is not rebuilt by words alone. It’s rebuilt by ownership, communication and delivery.”

Sound Like You?

The best solutions architects are genuinely curious about both sides of the screen: how the technology works, and what the business on the other end actually needs. If you light up at the technical detail but also love being in the room with the client, this might be your kind of role.

Ready to take the first step?

Visit Kohde careers to see current roles, or take a look at the work we do with clients across South Africa and beyond.