ENGINEERING DIGITAL SYSTEMS

Surf Start a Project
Back to insights
Process·April 12, 2026·4 min read

Engineered by Hand: Why Our Process Is a Sketchbook

Every product Surf has ever shipped started on paper. Here's why we still draw before we code, and what it does to the quality of the final build.

Surf Founder
writing from Port Harcourt

There's a moment in every project — usually around week two — where the team gets the urge to just start coding. The brief is clear enough. The stack is decided. Figma has a few screens. Why are we still talking about it?

We talk about it because the brief is never as clear as you think it is, and every minute spent sketching saves a week of building the wrong thing.

The cost of skipping the sketch

We learned this the hard way on a project we won't name. A client came to us with a clear spec: build a customer-facing portal for tracking deliveries. Six screens. Three weeks. They had wireframes from a previous consultancy.

We started coding. We were efficient. We were proud.

Three weeks in, we demoed. The client looked at the working product and said: "Oh, this isn't what we meant."

They didn't want a customer-facing portal. They wanted a customer-facing portal for internal staff to use on behalf of customers who couldn't access it themselves. The spec was right. The wireframes were right. The mental model was completely wrong — and we'd missed it because we hadn't sketched alongside them.

What sketching forces

When you draw a screen by hand — even badly — you have to make decisions a wireframe in Figma lets you avoid:

  • Who is looking at this? A hand drawing forces you to imagine the person.
  • What did they just come from? You have to draw the arrow.
  • What happens when they get stuck? You have to draw the dead end.
  • What's the simplest possible version? Pencils are uncomfortable. You ask less of them.

There's something about the friction of pen-on-paper that slows the team down at exactly the right moments. Tools that are too fast let you skip past the hard questions. A pencil makes you sit in them.

How we actually do it

Our discovery phase has three sketchbook moments:

  1. The Problem Sketch. One page. Hand-drawn. Who has this problem, when does it bite, and what do they do today? We don't draw solutions. We draw the wound.
  2. The Day-in-the-Life Sketch. A comic strip of the user's existing workflow. Eight panels, maximum. If we can't summarize their day in eight panels, we don't understand them yet.
  3. The Architecture Sketch. Boxes and arrows. Not on a whiteboard tool — on actual paper, photographed and pasted into Notion. The act of writing service names by hand is slow enough that you only write the ones that matter.

Once those three sketches exist, and only then, we open the laptops.

A note on tools

We're not anti-Figma. We're not anti-Excalidraw. We use both. We use Linear and Notion and GitHub and Vercel. We are not romantic about paper.

What we are romantic about is slowness in the right place. Build fast. Ship fast. Iterate fast. But sketch slow. The two hours you spend with a pencil at the start of a project pay for themselves a hundred times over by the time the thing is in production.

It's why our website looks the way it does. It's why our products feel the way they do. It's why our clients ship things that work.

We engineer by hand because hands force honesty. And honest software is the only kind worth building.

Got an idea worth building?

Whether you're building in Africa or sourcing engineering talent from it — let's sketch it together.