Software house without a frontend: you're delivering APIs and the client sees a desert. Why you need someone who closes the product

The API “is ready” and the client doesn’t know where to click

There’s a scene you know if you run a software house or a team that lives on backend. The project is technically finished. The APIs are documented, tested, fast. The endpoints do exactly what they should. The team is proud, and they’re right: under the hood there’s a serious engine. Then the demo with the client arrives, someone opens the screen, and the room goes cold. The client looks, doesn’t understand where to click, asks “wait… is this it?”, and in their head a thought forms that you don’t hear but that’s worth the contract: “I paid for a desert.”

It isn’t the client’s fault. It’s that the client doesn’t buy APIs. They don’t see them, don’t touch them, don’t even know what they are. The client buys the thing they open on the screen and use. For them, the product is the interface — and if the interface is four fields dumped on a page, a raw menu, bare tables that say “loading…” forever, then for them the product is that. All the work underneath, the solidity of the architecture, the elegance of the backend: invisible. It doesn’t exist. The client judges what they see, and what they see is a desert.

This is the silent wound of a lot of good software houses: racing engine, missing bodywork. And the paradox is that the team often knows, but has neither the people nor the head to close that piece — because doing serious frontend isn’t “putting a bit of CSS on top”, it’s a different discipline, and asking a great backend developer to do it reluctantly produces what it always produces: something that technically exists but that nobody would actually use.

I write this piece for whoever sits on this side: you have the backend, you’re missing the face, and every time you deliver you feel that the value you built doesn’t reach the client because it gets lost in the last mile. Let’s talk about what the missing frontend really is, why it isn’t the job you think it is, and how you work as two — your team on the engine, someone on the bodywork — without spending the days bouncing blame.

The product is the visible contract

Let’s start from a definition, because it’s the misunderstanding at the root of everything: the product is the visible part of the contract between you and the client. It’s the place where all the value you built becomes something a person can see, understand and use. If it stays invisible, for the client it was never built.

Think about what your work actually sells. You don’t sell “REST endpoints”. You sell the promise that the client will be able to do a certain thing — manage their orders, see their data, get their users working. That promise the client can verify in only one place: the interface. The frontend is where the contract becomes visible and checkable. It’s there that the client says “yes, it does what you told me” or “I don’t understand, it doesn’t work, you ripped me off”. There’s no appeal: whatever sits underneath, the verdict is issued looking at the face.

This has a consequence backend teams struggle to accept: the frontend isn’t the optional final phase, it’s where perceived value is born or dies. You can have the most elegant backend in the world, but if the client can’t use it, for them it’s worth zero — actually less than zero, because they paid and they get nothing. Conversely, even a modest backend dressed as a clear, usable product is worth a lot to the client, because they get what they wanted. Perceived value doesn’t follow code quality: it follows the quality of the experience.

It’s the same distinction I make talking about a showcase site versus a digital product, flipped: there the problem is whoever has only the showcase and not the engine; here it’s whoever has the engine and not the face. They’re two sides of the same error — thinking the product is only half of itself. A product is both the engine and the face, and whoever delivers only half delivers something the client can neither use nor appreciate.

What a serious frontend actually does (and why it isn’t “a bit of CSS”)

Here’s the misunderstanding that ruins projects. Whoever doesn’t do frontend thinks it’s “showing the data”: take the API response, put it in a table, add two colours, done. If that were it, you’d be right to treat it as a detail. But a serious frontend — the one that makes the difference between “the client works with it happily” and “the client complains every day” — is made mostly of the things that aren’t the happy path. It’s made of states.

A real interface has to handle, for every single thing it shows:

• The loading state. What does the user see while the API responds? If they see a white page or a frozen block, they think it’s broken. A serious frontend shows that it’s working, so the wait is bearable and clear.
• The error state. The API answers badly, the network drops, the permission is missing. What does the user see? If they see “undefined” or a screen that explodes or the classic “something went wrong”, you’ve lost. A serious frontend translates the error into something understandable and actionable: what happened, what they can do. This is the part where the product most often collapses, and it’s exactly the same dynamic I describe in the errors that make people abandon a flow: a mute error is a lost user.
• The empty state. The client comes in the first time and has no data yet. What do they see? If they see an empty table and that’s it, they feel lost and think “it doesn’t work”. A serious frontend uses the empty state to guide: “you don’t have any orders yet, start here”. The empty state is the client’s first moment with the product, and it’s where they decide whether they can find their way or not. Backend teams always forget it, because in their tests the data is already there.
• Permissions. Different users see and can do different things. A serious frontend doesn’t show buttons that then throw “unauthorized”: it shows each person only what they can do, and it does it consistently across the whole app.

That’s why “a bit of CSS” is an illusion. The happy path — data present, API answering well, user with all permissions — is 20% of the work. The other 80% is the states: loading, errors, empties, permissions, edge cases. That’s where the real experience lives, and that’s where a backend developer put on frontend against their will cuts corners, because those are exactly the cases their tests don’t see. The result is an interface that “works in the demo” and collapses the first real day, when a real user does the real thing nobody had predicted.

A design system, not “the pretty page made once”

There’s a second error, opposite and equally expensive: calling a designer or a UI freelancer to make “the pretty page”. You get a careful screen, maybe splendid, delivered as an image or an isolated page. And then? Then the product has another thirty screens, and each one has to be done from scratch, and none looks like the others, and every time you add a feature you start arguing again about what colour the button is. You bought a painting, not a way of building.

What a living, growing product needs isn’t the pretty page once: it’s a design system. Meaning a coherent set of reusable components — how buttons, fields, tables, error messages, empty states are made — and the rules for using them. With a design system, the thirtieth screen is built in a day using pieces that already exist and already work, instead of in a week of discussions. And above all: the whole product looks like one thing, coherent, professional, instead of a patchwork of pages made at different times by different hands.

The difference is between a cost that pays itself back and one that repeats. The pretty page once is a cost you pay every time, because it leaves nothing behind. The design system is an investment you pay once and that speeds up everything that comes after: every new feature costs less to dress, every new developer understands how to build, every screen is coherent with the others without effort. For a software house that delivers products on repeat, this is the difference between frontend as a permanent bottleneck and frontend as a machine that runs.

And — a point that touches your margin — a well-made design system is reused across projects. The way you handle tables, forms, errors that you build for one client becomes the base for the next. Which takes us straight to why all this, for you, isn’t a cost but a commercial lever.

How two teams work without spending the day bouncing blame

The legitimate fear, when you think of putting someone next to your team for the frontend, is the ping-pong. You know it: “it’s the frontend’s fault for calling the API badly”, “no, it’s the API that answers in a ridiculous way”, and in the middle there’s you refereeing while the project is stuck. If the collaboration produces this, better nothing. So the real question isn’t “do I need a frontend?” but “how do you work as two without it becoming a border war?”.

The answer sits in a few things, and they’re all manageable:

• The API contract is the frontier, and it has to be written. The point where the two worlds touch is the shape of the data the API exposes. If that shape is clear, documented and stable, the two teams work on the two sides of the border without stepping on each other: the backend guarantees that shape, the frontend consumes it. The ping-pong is born when the border is vague or changes without warning (I’ll come to that in a moment). With a clear contract, 90% of the fights never even start.
• You work in parallel, not in sequence. The classic error is “first we finish the backend, then we call the frontend”. That way the frontend arrives to a done deal, discovers problems late, and every change costs triple. Whoever does serious frontend can work together with the backend from the start, working on fake data (mocks) that respect the agreed contract, so when the API is ready the interface is already there waiting for it. And data-design problems surface early, when they cost little.
• Someone has to understand both sides. And that’s the heart of everything. The ping-pong explodes when the frontend is someone who “only knows CSS” and doesn’t understand what an API does, and the backend is someone who has no idea what the frontend needs. When instead on the other side you have someone who understands both the data and the interface — who can read your API contract, who can tell you “I need this datum in this other shape, and it makes sense because otherwise the user has to click three times”, who speaks your technical language — then there’s no referee to play. There’s a conversation between peers.

This is the point where my way of working makes the difference compared to picking any UI freelancer: I come from doing data, backend, frontend and LLMs all together. When I sit next to your team, I’m not “the CSS guy” who treats your API as a black box. I understand what’s underneath, I discuss the contract with you as a technician, and I close the face of the product knowing what happens behind. It’s the same logic of the single pair of hands I bring everywhere — only here the hands add to yours, they don’t replace them: you keep the engine you know how to do extremely well, I close the bodywork speaking your language.

If the data and the API contracts change every day, the UI dies

I have to tell you the most uncomfortable thing, the one that decides whether a frontend collaboration works or turns into a nightmare: if the API contract changes constantly with no discipline, no frontend can hold.

The interface is built on top of the shape of the data you pass it. If today a field is called this, tomorrow it changes name, the day after it disappears and becomes two fields, and nobody says so — the UI breaks continuously, the frontend spends the days chasing changes instead of building, and you get exactly the ping-pong you wanted to avoid. Not because the frontend is weak: because it’s building on quicksand. It’s like asking a bodywork shop to finish the car while you change the chassis every morning.

This does not mean the backend can’t evolve — of course it evolves, always. It means evolution has to be governed, and these are things you already know how to do as a serious software house:

• The contract is versioned. If a change breaks the shape of the data, you don’t change it under someone’s feet: you make a new version, and the frontend migrates when it’s ready. Announced breakages are manageable; surprise ones aren’t.
• You communicate the change. Even just a message: “tomorrow this endpoint changes, here’s how”. The frontend prepares instead of discovering it when everything explodes in production.
• You distinguish what’s stable from what’s in motion. The parts of the API the frontend uses a lot stay still; you experiment where it doesn’t do damage.

I tell you this frankly because it’s the real compatibility test between your team and whoever does the frontend. If your backend is disciplined on the contract, the collaboration flies. If instead the API is a building site that changes every night with no rules, then the problem to solve first isn’t “finding a frontend”: it’s putting the contract in order. And whoever understands both sides tells you immediately, instead of taking the job and then complaining — because they know that a UI built on a chaotic API is burned time for both.

White-label: the face becomes their face (and your margin)

Now the part that turns frontend from a cost into a business lever for a software house. Many of your clients don’t only want to use the product: they want to put it in front of their clients, with their brand. They want to resell what you build as if it were theirs. That’s white-label, and it’s gold — but it only works if the face of the product is made to be re-branded.

If the frontend is built well — with the design system above, with colours, logo and style that change from a single point — then the same product can wear twenty different faces for twenty different clients, without rebuilding it twenty times. Your client sells it as theirs, their users see their brand, and behind it you have one product to maintain. This multiplies the value of what you’ve built: from “a project for one client” to “a platform that many clients resell”. It’s a model that changes a software house’s numbers, and I go deeper in launching a white-label AI product.

But — and here it all comes back together — white-label is possible only if the frontend was thought to be so from the start: coherent components, centralised style, no colours scattered by hand across thirty screens. If instead you have the “pretty page made once” with the brand glued inside, white-label is a rebuild for every client, and the model doesn’t stand. It’s yet another reason why serious frontend isn’t an accessory to bolt on at the end: it’s product infrastructure, and how it’s made decides which business models you can afford. All of this lives in the web and digital product cluster, because the face of a product isn’t aesthetics: it’s what determines whether and how you can sell it.

Perceived speed is frontend work

There’s a last piece backend teams underestimate because “it concerns performance, and we do performance”: perceived speed. And it is, in large part, frontend work.

Here’s the paradox I see often: the backend is extremely fast, the APIs answer in milliseconds, and yet the product feels slow and heavy to use. Why? Because the speed that counts for the client isn’t the one measured by your monitoring: it’s the one they feel with their finger. And that depends on how the frontend is built.

An interface can throw away all your backend’s speed in ways you don’t even see from the server side:

• It loads everything at once when it isn’t needed. It downloads thousands of rows to show twenty, or pulls down half the world at startup instead of taking things when they’re actually needed. The backend answers fast, but the user’s browser struggles under the weight. A serious frontend takes only what’s needed, when it’s needed.
• It never gives the sense that it’s working. Between the click and the response, if the screen stays still and mute, the user perceives slowness and lag even when the data arrives fast. A serious frontend reacts immediately to the gesture — a signal, an instant change — so the wait, even a short one, is lived as fluid instead of as a freeze.
• It reloads things it already had. If every navigation does the work already done from scratch, the product feels stuck. A serious frontend remembers what it already has, and doesn’t make the server (and the user) do the same labour twice.

The point is that speed is an experience, not only a number on your dashboard. A racing backend dressed in a heavy frontend delivers to the client the sensation of a slow car — and the client judges the sensation, not the benchmark. It’s exactly the phenomenon I analyse in why a slow site makes users err: perceived slowness erodes trust and makes people leave, and a large part of that slowness is gained or lost in the last mile, on the face. Throwing away your engine’s speed in a heavy bodywork is a double waste: you paid for a fast backend and you deliver it as if it were slow.

The cost of delivering “the desert”

Let’s do the accounts of inertia, because it’s concrete and you live it. What does it actually cost you to deliver backend without a serious face?

• Deals lost at the demo. How many times has a technically convinced client gone cold seeing the raw interface? Every contract lost there is a whole project walking away, and the cause wasn’t your work — it was the last mile not done. A single deal recovered in a year more than pays for the investment on the face.
• Hours of your good developers burned doing frontend reluctantly. Your backend developers cost, and they’re good at backend. Every day they spend fighting CSS and making interfaces they don’t know how to make is time paid dear, produced badly, and subtracted from what they’re strong at. It’s the worst possible use of your best resources.
• Endless maintenance of the patchwork. A frontend made of disconnected pages, with no design system, is a debt you pay at every change: every modification touches ten different points, every new feature costs an argument. The cost isn’t the build, it’s the drag of a thing made without structure.
• Business models you can’t catch. No serious white-label, no resellable product, no scale. You stay selling projects by the hour instead of building platforms that multiply.

Added up, these are figures that far exceed the cost of closing the product properly. The “desert” isn’t free: you pay it in lost deals, wasted hours and growth that doesn’t arrive — only you don’t see it on an invoice, and that’s why you underestimate it.

It’s for you if / it isn’t for you if

It’s for you if:

• you have a solid software house or backend team and you’re systematically missing the face of the product;
• at demos you feel that the value you built doesn’t reach the client because the interface is raw;
• your backend developers lose time doing frontend that isn’t their job;
• you want to offer clients white-label products, resellable, but the current frontend isn’t thought to be so;
• your API contract is disciplined (or you’re willing to make it so): that’s the condition for the collaboration to work.

It isn’t for you if:

• you only need a pretty page once, an isolated landing: there a designer is enough, not a product partner, and I tell you that honestly;
• your backend is a building site that changes every night with no rules: first the API contract has to be put in order, otherwise any frontend is burned time;
• you’re looking for someone who treats the API as a black box and doesn’t ask questions: I ask the questions, because that’s how the product comes out well — if you want a mute executor, I’m not the right person.

The collaboration model, without surprises

Concretely, how we work together. Not “I send you a quote and disappear until delivery”, but a model thought for two teams that have to fit.

First you align the border. We look together at the contract of your APIs, what they expose, how stable they are. We define the shape of the data at the point of contact. This phase is technical and honest: if it emerges that the contract needs fixing first, I tell you, because building on it without that would be a waste for both.

Then you build in parallel. I work on the face — design system, states (loading, errors, empties, permissions), the screens — while your team works on the engine, on the agreed data. I don’t wait for you to finish: I build on the agreed data and hook onto the real API as it becomes ready. Problems surface early, when they cost little.

The border stays clean. You stay the owner of the backend and of the relationship with the client. I close the product. When something doesn’t add up, you look at the contract: it’s the agreed frontier, and it says whose turn it is — no ping-pong, because the border is written.

The model can be a single project (“let’s close this product”), a recurring collaboration (“you’re my frontend for the projects that need it”), or building a reusable design system that your team then carries forward. It depends on what you need, and we decide looking at your projects, not a price list.

Frequently asked questions

Can’t I just have my backend developers do the frontend? You can, but you pay your best resources to do badly a job that isn’t theirs, taking them away from what they’re strong at. Serious frontend — states, errors, empties, design system — is a different discipline from backend, and “a bit of CSS on top” produces interfaces that collapse at the first real user.

How do we avoid the classic frontend-backend ping-pong? With a clear, versioned API contract as the agreed frontier, working in parallel instead of in sequence, and with someone on the frontend side who actually understands data and APIs — not someone who treats them as a black box. The ping-pong is born from a vague border, not from collaboration itself.

What if our APIs change often? Evolving is fine, changing by surprise isn’t: if the contract mutates every night with no discipline, no frontend holds and you build on quicksand. The solution is to version breakages and communicate them. If needed, fixing the contract comes before building the face — and I tell you that immediately.

Do I need a pretty page or a design system? If you have a product that lives and grows, a design system: reusable components that make thirty screens coherent and make every new feature cost less. The pretty page once is a cost you pay every time; the design system is an investment that speeds up everything else and enables white-label.

Will I be able to resell the product white-label to my clients? Yes, if the frontend is thought to be so: centralised style, brand changeable from a single point. That way the same product wears many faces without rebuilding it every time, and you maintain one platform. But it has to be designed that way from the start — with the patchwork it doesn’t work.

Who stays owner of the backend and of the client? You. The model is collaborative: you keep the engine you know how to do and the relationship with the client, I close the face of the product. The API contract is the clean frontier between the two worlds.

Do we work as a single project or ongoing? As you need: a single product to close, a recurring collaboration as the frontend of your projects, or a reusable design system that you then carry forward. We decide on your real projects.

Why you and not any UI freelancer? Because I come from doing data, backend, frontend and LLMs together: I understand what’s under your API and I speak your technical language, instead of treating it as a black box. That eliminates the ping-pong and makes the product come out well, because I discuss the contract as a peer, not as a mute CSS executor.

In one line

A software house without a frontend delivers a racing engine and a desert: the client doesn’t buy APIs, they buy the face, and that’s where the contract becomes visible. Serious frontend isn’t “a bit of CSS” — it’s states (loading, errors, empties, permissions), a design system that you reuse, perceived speed. Two teams work when the API contract is a written, versioned frontier and someone on the UI side speaks the language of the data. White-label, the lever that multiplies a platform, is possible only if the face was designed to be re-branded from the start.

If you have a backend that deserves a face to match, look at the projects I’ve built or drop me a line: we start from your API contract and from the last mile the client actually sees, not from a pretty page made once.