Notes from a software agency that shouldn't have survived

Six people, three rooms, an espresso machine that screams. What I learned working with a small software agency in Lisbon that has outlasted three economic cycles.

The software agency I want to tell you about is in Lisbon, in a building that used to be a small bakery. There are six people. One of them is the founder, a woman named Inês who is forty-three and has the calm intensity of someone who has, twice now, watched a freelance market collapse from the inside. The other five are engineers and a single designer who insists on being called the design department.

The bakery had three rooms when it sold flour. It has three rooms now. The first room has four desks. The second room has two desks and a couch nobody uses. The third room has the espresso machine, which makes a sound when it's grinding that I once described — to Inês's face, and to her quiet displeasure — as "a small animal in distress."

The agency has been in business for eleven years. It has survived two financial crises and one pandemic. It is not large and it has no plans to become large. It does not have a flashy website — and I have, in fact, offered to redesign it, and been declined. It has a wait list of nine months. Its clients are SaaS founders, consumer-products startups, and the occasional foundation that needs an internal tool.

I have spent enough time at the bakery over the past four years to know how the place runs. Here are the four things I think are true about why a small software agency — or a dev agency, or a product studio, or whatever name you want to put on a group of six people who build things for clients — survives.

1. They turn down the wrong work

This is the unfashionable answer, but it's the right one. Inês's agency turns down two clients for every one they take. They turn down clients whose budgets are wrong. They turn down clients whose timelines are wrong. They turn down clients whose founders are, to use Inês's exact word, difficult.

The way she says no is the most studied move in the company. She never says "no." She says: "I think you'd be better served by [agency name]. They handle [thing] better than we do. I can introduce you." The introduction is real. The compliment is real. The agency she names is almost always a friend.

What this builds, over eleven years, is a network of dev agencies who refer to each other. When Inês's agency is full, she sends the overflow to a friend. When the friend's agency is full, the overflow comes back. Nobody starves. Nobody fights for the same RFP. It is the most quietly cooperative software-agency ecosystem I have ever seen, and it exists because she said no, politely, two thousand times.

The corollary

If you run a small dev agency, the single highest-leverage skill you can develop is the polite no. Not the firm no. The polite no, with a real referral attached. It costs you the project. It builds the network that feeds you for a decade.

2. They have a real opinion about everything

Inês's agency has, written in a Google doc that all six employees can edit, a list of opinions. There are about forty of them. Examples:

  • We do not build with Webflow except for marketing sites under twenty pages.
  • We do not ship dashboards with more than two accent colors.
  • We do not use stock photography of people.
  • We do not ship a landing page without a real testimonial from a real user.
  • We do not write copy in the voice of "we." The product speaks. Not the company.

Some of these opinions are aesthetic. Some are technical. Some are operational. The point is not that any one of them is correct. The point is that the agency has them, knows them, and uses them to say no to client requests that violate them.

When a SaaS client asks for a stock photo of people in a hero, Inês does not say "sure, our designer will source one." She says "we don't do that, here is why, here is what we'd do instead." Sometimes the client pushes. Most of the time the client agrees. The few times the client refuses, Inês considers it a successful screening.

The list of opinions as a hiring tool

New hires get the list on day one. They are encouraged to disagree with any opinion on the list, in writing, in the document itself. If their disagreement convinces the team, the opinion gets revised. The list has been revised, by my count, eleven times in four years.

This is the most underrated agency-building move I have seen. Most small agencies have implicit opinions held by the founder, and the engineers either guess at them or override them. The bakery's list makes the opinions explicit, which makes the work consistent. Consistent work is the only thing a small software agency has, against larger competitors with deeper pockets.

3. They learned to read the launch video before the brief

Inês does a thing in the first client meeting that I have never seen another agency do. She asks the founder to send her the three launch videos they wish their company looked like. Not landing pages. Not products. Launch videos. The thirty-to-ninety-second pitch films.

The founder usually sends a Linear product launch, a Notion AI launch, and something off-genre — a Tesla reveal, a Patagonia campaign, a Loewe runway. The three videos tell Inês more about the founder's taste than a brief ever does. A brief is what the founder thinks they want. Launch videos are what they actually respond to.

She then builds the engagement around the gap. If the founder sends three Linear-style launch videos and a brief that asks for an "AI-forward gamified experience," Inês knows the engagement is going to be a slow education in restraint. She prices accordingly. She paces the project accordingly. She has, on three occasions, used the gap to politely decline the project — because the gap was so wide that the engagement was going to be a fight.

It is the most diagnostic question in agency new business. "Send me three launch videos you wish you'd made." Try it next time. You will learn more in twenty minutes than you would from a forty-page RFP response.

4. They edit each other with one purple pen

This is the part that I think is unteachable, and is also the part that is most worth teaching.

Inês's engineers — the four of them, plus the design department — review each other's pull requests with extreme restraint. Their code reviews are short. Their comments are blunt. Their suggestions are almost never "do it this way instead." They are almost always "this part isn't earning its space, what do you think."

I read three of their PR reviews when I visited last September. The longest review had four comments. The longest comment was two sentences. The PR was a fairly large refactor of a SaaS onboarding flow. The four comments together must have saved the engineer six hours of rework. They were that surgical.

I asked Inês where the culture came from. She said: "From the bakery." I said I did not understand. She said: "The woman who used to run this place baked the same loaf, every morning, for thirty-one years. She used to tell me — I worked here for two summers when I was a teenager — that a baker who tastes every loaf they make never makes a great one. You have to trust the recipe. You only taste when something is wrong."

I think about that a lot. The senior engineer who comments on every line of every PR is the baker who tastes every loaf. They are not making a great loaf. They are making sure no loaf is bad. Those are different jobs.

What this means for your dev agency

If you run a small dev agency, or are about to start one, or are working at one and thinking about leaving, here is the playbook I would steal from Inês:

  1. 01Build a network before you need it. Refer aggressively. Refer to direct competitors. The favor returns within a year and lasts a decade.
  2. 02Write your opinions down. Forty of them. Revisit quarterly. Hire by the list. Sell by the list. Say no by the list.
  3. 03Ask the launch-video question. Three videos they wish they'd made. Build the engagement around the gap between those videos and the brief.
  4. 04Code-review with a purple pen. Mark the three things that aren't earning. Don't rewrite. Trust the engineer.
  5. 05Stay small. Inês's agency is six people because seven would change what the work feels like. If you can afford six and resist seven, you will outlast every competitor who scaled.

The bakery, last visited

I was in Lisbon two months ago. The espresso machine still screams. The third desk in the second room is still empty, because Inês has refused to fill it for four years, because she does not want a seven-person company. There is now a small purple pen on each desk. I do not know who brought them. I asked Inês. She smiled and said "a gift from a friend." I have never given anyone in that bakery a pen, purple or otherwise.

I am writing this from a café two blocks from the bakery, on the morning of a day when I am about to meet with a small software agency in another city about a project that will probably not happen. The reason it will probably not happen is that I asked them to send me three launch videos they wished their company looked like, and the three videos they sent are wildly inconsistent. The brief, when it arrives, will look like all three videos at once. I will, politely, decline.

Inês taught me that, too.

Keep reading