I work out what actually needs building.
Most technical people are trained to optimise the thing in front of them. That is genuinely valuable, and it is not the same as knowing whether the thing in front of them is worth optimising.
● samuel_pedroI have been running businesses since I was 14 and selling software since around 2019, first through SP Business Group, the agency I ran in Lisbon. In 2024 I founded No-Code District in London, now 42 District - over a hundred products and something north of a thousand automations since, across finance, real estate, healthcare and hospitality.
The academic route was not a straight line, and the part that looks least relevant matters most. My Master's is in sports sociology and organisational development: why a group organised around a shared goal produces the results it does, what the structure rewards, and what it quietly punishes. Replace sport with company and it is the question I get paid to answer now - a system is a set of people and the tools they have arranged themselves around, and the interesting part is almost never the tool.
I paused the PhD to keep growing the business, and picked up an MBA and a second Master's in innovation and entrepreneurship in Barcelona - the commercial half of the same argument. All of it trained one habit.
Almost every engagement I take starts with a stated problem that is not the real one.
The stated problem is what the business can see. The real one is usually a step earlier, cheaper to fix, and less satisfying to talk about.
At We Complement the ask was a faster way to produce quotes. The actual problem was that the pricing rules existed only in people's heads, which meant two advisors could quote the same case differently and both be defensible. Writing those rules down explicitly, including the ones nobody had ever articulated, was most of the value. The calculator was the easy half, and it only worked because the mapping came first. Quotes now take under two minutes, and two advisors reach the same number.
At Barnes Yachting the stated problem was six systems that did not talk to each other, which sounds like an integration project. The binding constraint was that no single record existed for a deal: brokers held the relationship, the website held the enquiry, the inbox held the conversation, and leadership held none of it. Connecting those systems without first deciding where the truth lived would have moved the same confusion around faster. Putting the CRM at the centre instead cut manual process by around 60%.
Qualaro had the opposite problem: nothing built, designs finished, and beta users already waiting. On a new build the risk is not what to fix, it is which decisions are expensive to reverse later. Two mattered. Splitting the stack so the front end could move fast without putting the data in a place it would outgrow, and metering usage from day one, because every AI feature in the product costs real money per call and you cannot price what you never recorded. Working MVP in twelve weeks.
Pink Coconuts is the one where I talked a client out of the bigger project. The platform looked past saving and a rebuild was the obvious answer, as well as the easier sell and the larger fee. The audit said the foundation was sound and only the accumulated mess was not, so I repaired rather than replaced. Less time, less money, and a working platform at the end of it.
That last one is the point. Sometimes the honest answer is that you do not need the thing you asked me to quote for. That conversation costs me revenue, and it is why two of the four clients above became fractional seats.
How I work.
Work out what actually needs building.
The stated problem is what the business can see. The real one is usually a step earlier, cheaper to fix, and less satisfying to talk about.
Ship, then theorise.
I'd rather put a working v0 in front of ten people than write a deck about v3. The deck is never wrong; the v0 usually is, which is the useful part.
Small surface, sharp edge.
Three ways to work with me, and no fourth. I'd rather do a narrow thing properly than be available for everything.
Name the trade-off.
Every technical decision costs something later. I write down what, so the next person inherits the reasoning and not just the code.
How it has gone.
First business. It has never really switched off since.
SP Business Group, in Lisbon. Strategy, brand and digital for SMEs.
The work turns to software: websites, e-commerce, internal tools.
Founded No-Code District, in London.
42 District, and three fractional seats.
Grow 42 District, and build the small AI-powered systems that show up in its clients' results.
I hold three fractional seats: AI Lead at We Complement, CTO at MineTrade, Digital Operations Lead at Silver Economy. Those are the engagements I love the most, because they are the ones where I am inside a team rather than delivering to one. When the work needs more hands than one person has, it runs through 42 District.
Most of my attention right now goes to what has actually changed about building software, rather than what people say has changed. I build with AI tooling in production every week, including the parts where it fails, and I write up what I find as I go.
That's the story. Here's how I work.
Three ways in, with prices, and what happens after the call. Or read the case studies if you'd rather see the work first.