Build the face first

building a product is very different from building a model. a model can exist anywhere - your local machine or a Github repo, a Python script or a Jupyter notebook.

a product is different. it doesn’t just have a model (the brain). it needs a data pipeline (the organs, veins, capillaries). and ultimately, it needs a frontend. the face.

diary of a startup CTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

and the uncomfortable truth is: for most users, the face IS the product.

users don’t see your model. they don’t care how elegant your architecture is. they only experience what’s in front of them. and if the interface is confusing, the product just feels dumb, even if the model behind it is state-of-the-art.

but frontend design isn’t just for users; it’s just as critical for developers. because if you don’t know how the output will be consumed, you don’t know what to build.  

you can’t design the right data structures.

you can’t shape the right outputs.

you don’t even know what “good” looks like.

look at ATMs. banks didn’t merely build a machine that connects to their backend systems and then figure out the interface later. the interface DEFINED the system.

1. insert card.
2. enter PIN.
3. choose action.
4. confirm amount.

that flow dictated everything behind the scenes. transactions had to be structured a certain way. limits had to be enforced. errors had to be handled cleanly.

this is all because of how a user interacts with a screen. if the interface was confusing, people wouldn’t trust it with their money. so the system had to be designed around clarity, predictability, and control.

it’s the same with AI or machine learning products. the interface isn’t just where the model shows up. it defines:

• what outputs are needed
• how decisions are made
• what the system even needs to do

this became very real for us. we spent 3.5 months building a Proof of Concept (PoC). a 4-person team, bootstrapping, and… we were stuck. not because we couldn’t build. but because we didn’t know what we were building towards. we had no clear interface, no “face” of the product. so everything underneath - the model, the pipeline - felt directionless.

eventually, I took on the design. not through workshops or focus groups. just research, quiet thinking, and a random eureka moment lying awake at night. a few principles anchored me:

1. what tools do our target users already use and what do those interfaces look like?
   most tools aren’t blank, they’re structured: lists, dashboards, timelines. the interface already guides how people think and act.
2. what decisions do they actually make daily, weekly, monthly?
   good interfaces don’t just show information. they support decisions: what to do next, what to prioritise, what to ignore.
3. what patterns are they already familiar with, what feels intuitive without explanation?
   people don’t want to learn a new system every time. they lean on patterns they already know: calendars, cards, flows.
4. how do we keep everything minimal and focused?
   if something doesn’t help a decision or action, it probably doesn’t need to be there.

once the interface became clearer, everything else followed. the model outputs became clearer. the pipeline had structure. the product finally had direction.

we often treat frontend as the final layer, something you add after the “real work” is done. but in reality, it should come much earlier. because the interface defines:

• what the system needs to produce
• how intelligence is experienced
• and whether the product feels useful at all

you can have the best model in the world. but if you don’t know how it shows up, you don’t yet have a product. ultimately, you’re not building a system. you’re designing how intelligence is experienced.

i’m starting to think most AI products fail not because of the model… but because no one designed the interface early enough. and maybe it’s the same mistake we make with domain knowledge (i wrote more about that here). we treat it as something to “add in later”, instead of something that should shape the system from the start.

and when we do think about interface, we default to what already exists. safe patterns. familiar designs. just rinse and repeat. like turning everything into a chatbot (more of that here).

curious how others approach this - do you start with the model, the domain, or the interface?

‍