Three weeks of research before a single line of code — and why the most expensive mistakes in a venture are made in the first architecture conversation, not the last sprint.
The setup
For the past few weeks I have been planning Tendrilo, my first product intended for the App Store. The idea is simple enough to explain in one sentence: it shows you the people who matter across work, family and hobbies, remembers when and what you last spoke about, and tells you when a connection is slipping — with a concrete reason to reach out.
The concept was finished. The brand was finished. The logo, the colour system, the typography, the interaction prototype — all done. What I had not done was write a single line of code.
That turned out to be the most valuable thing about the project so far. Because the research phase killed roughly a third of my product, changed my cost base by a factor of five, and taught me that the questions I was asking were the wrong ones.
The first surprise: half the product was impossible
Tendrilo’s premise depends on knowing when you last spoke to someone. The obvious source is WhatsApp. Everyone uses it, the data is right there on the phone, and the feature practically designs itself.
It cannot be done. On iOS there is no API, no shared container, no notification access. On Android there is a technical route through the notification listener, but Google’s policy treats reading messenger content as exactly the kind of thing it rejects. This is not a difficult integration. It is a closed door.
Instagram was worse, and more instructive. Someone told me that access was possible through a third-party provider using MCP — the protocol everyone is currently excited about. I spent an afternoon establishing whether that was true.
It is true, in the same way that a lockpick is a key. The Instagram Basic Display API — the only interface that ever allowed a third party to read a personal account — was shut down on 4 December 2024 with no replacement. It took Instagram features out of Tinder, Hinge and Discord on the way. What remains requires a Business or Creator account, and professional Instagram accounts cannot be private.
So how do those MCP servers work? They take your user’s Instagram username and password and log in with the user’s own credentials against the private mobile API. That is a terms-of-service violation, and the account that gets suspended is your customer’s, not yours.
This is where I learned something that generalises well beyond apps:
MCP is a calling convention, not an access grant. It carries no credentials of its own and has no privileged relationship with any platform. If the underlying API does not expose the data, no wrapper around it can. Strip away the MCP layer and you are left with a scraper.
Spotify and Strava taught the same lesson from a different angle. There the wall is not technical at all — it is contractual. Strava’s API policy, effective 1 June 2026, states plainly that data from one user “may be displayed or disclosed … only to that user” and may not be shown to others “even if such data is publicly viewable.” No quota tier changes that. No consent from the friend changes that.
Half of what I had drawn on the whiteboard was unbuildable. Not hard. Unbuildable.
The one decision that changed my costs by a factor of five
I originally designed Tendrilo to keep everything on the device. Then I decided a cloud version was necessary for sync and reliability. That single change moved me from “barely regulated” to “fully responsible controller under GDPR” — because the app stores notes about roughly eighty people per user, and those people never consented to anything.
Free-text notes about eighty friends will, over time, reveal health, religion, politics and relationships. Under GDPR that is special category data, and the usual legal basis of legitimate interest is not available for it.
Then it gets worse in a way I did not see coming. The German supervisory authorities publish a list of processing operations that always require a data protection impact assessment. Entry 9 of the list for the private sector reads: the creation of comprehensive profiles about the interests, the network of personal relationships or the personality of data subjects. I did not have to argue my way into that entry. It is a one-line description of my product.
And any processing that requires an impact assessment triggers, under § 38(1) sentence 2 of the German Federal Data Protection Act, a mandatory data protection officer irrespective of headcount. The twenty-employee threshold most founders have heard of is in sentence 1, and it does not apply here. Being Swiss does not get me out of it: § 1(4) no. 3 extends that Act to controllers with no establishment in the EU who fall within the GDPR’s scope. My own Swiss law makes the same role voluntary. Same product, same data, different postcode of the customer.
That chain — a stored relationship graph → mandatory impact assessment → mandatory officer — was going to cost me somewhere between €3,500 and €5,000 in the first year.
Client-side encryption of the content fields is the highest-leverage change available. Two to three days of extra engineering. The server stores pseudonymous identifiers, timestamps and counts in the clear, so it can still detect that person a7f3 has gone quiet and fire a notification. It simply does not know that a7f3 is Anna.
I want to be careful here, because this is where I first talked myself into something too good. Encryption removes the special category problem completely, because there is no readable content left to be special. It does not by itself remove entry 9, which describes a data model, not a file format — a graph of relationships with interaction frequencies is still a graph of relationships. What encryption buys is that the threshold assessment can point at a mitigation instead of at a hope. It converts a certainty into a position I have to be able to defend in writing.
First-year cost if that position holds: €500 to €700. If it does not, add an external officer at roughly €100 to €300 a month.
And one obligation I could not design away at all: as a Swiss company with no EU establishment serving people in Germany, I need a representative in the Union under Article 27. From about €350 a year, permanently. It is worth sorting your obligations into the ones that are engineering problems and the ones that are simply invoices.
This is not a privacy story. It is an architecture story. The encryption decision was not made for marketing reasons and it was not made for ethical reasons. It was made because a two-day engineering choice turned a €3,000 recurring obligation from certain into arguable. You only see that if you map the regulatory consequences of your data model before you build it, not after — and you only see the limits of the fix if you then go and read the actual list.
The pricing trap nobody puts on the landing page
I am building on Supabase. For a first product it is genuinely excellent: a Postgres database, authentication, file storage and an auto-generated API, connected to Claude Code in about ten minutes, running in a Zurich region, free to start.
Here is what the pricing page does not make obvious.
The Pro plan starts at $25 per month. Compute is billed separately, per project, and the $10 of monthly compute credit is granted once per organisation — not per project. So a production project plus a staging project already costs $35 to $40 before you have stored a byte. Point-in-time recovery is $100 per month for seven days of retention — the same capability costs €0.70 at IONOS, €3 at Scaleway, and is included in the tier price at Exoscale. And egress runs at $0.09 per gigabyte beyond the included allowance, which at two terabytes a month is $157 — a line that is effectively zero at providers that include traffic.
Run the numbers across three stages and the picture is clear:
| Users | Supabase | Scaleway managed | Self-hosted |
|---|---|---|---|
| 100 | ~€37 | €24 | €20 |
| 2,000 | ~€78 | €45 | €27 |
| 20,000 | ~€292 | €168 | €71 |
At launch scale the difference is noise. At traction scale it is four times.
The conclusion is not “don’t use Supabase.” It is the opposite. Use it, because time to first working endpoint is the scarcest resource you have. But use it with a rule:
Keep the schema generic. Plain Postgres, standard SQL, no dependency on vendor-specific edge functions or proprietary abstractions. Treat the convenient platform as a rented starting position, not an address.
That rule costs nothing while you are small and saves a rewrite when the bill starts to bite. It is the same discipline as not letting your iOS-only decisions calcify when you know Android is coming — a habit, applied early, that turns a future migration from weeks into days.
The frameworks I should have applied on day one
Here is my honest confession. I did all of the above — three weeks of API research, regulatory analysis, provider comparison, cost modelling — before I had rigorously answered a much more basic question.
Who is this for, and what will they pay?
I had priced Tendrilo at CHF 4.50 per month. The comparable products — Dex, Clay, Covve, Monica — sit between $9 and $12. I was at roughly half the market rate, and I had not thought hard about what that does.
It does two things. It makes paid acquisition structurally impossible, because the lifetime value cannot carry the ad cost. And it doubles the number of subscribers required for every revenue milestone. The lower bound of the Swiss seed benchmark is around CHF 200,000 in annual recurring revenue. At CHF 4.50, minus the app store’s cut, that is between 4,300 and 5,300 paying subscribers. At CHF 8.90 it is roughly half that.
There are two frameworks I know from executive education that would have surfaced this on day one, and I did not use either.
Minimum Viable Segment
The first is Michael Skok’s Minimum Viable Segment, from the Startup Secrets programme he teaches at Harvard. The definition is elegantly brutal:
Minimum = small enough to dominate. Viable = you can succeed with your MVP.
You find your segment where five circles overlap: pain points, customer profile, product use case, channel, and — the one I skipped — budget.
Budget is not a pricing question. It is a segmentation question. How much will these specific people spend to solve this specific problem? If you cannot answer that before you build, your price is a guess dressed as a decision. And a wrong price is not a marketing problem you can fix later; it determines whether paid acquisition, investment and even your own salary are arithmetically possible.
Notice also that four of the five circles were things I had genuinely thought about. Channel and budget were the two I had waved at. That is not a coincidence — engineers and product people converge naturally on pain, profile and use case, because those are the fun ones.
The Diamond
The second is the business model Diamond, from Thomas Eisenmann’s business model analysis at Harvard Business School. It asks whether a venture can create, deliver, make money, and do so sustainably across four corners:
Look at where I had spent three weeks. Entirely in TOM. Which providers, which encryption, which framework, which APIs, which region. Real work, correct answers, and one full corner of a four-corner model.
My CVP was strong — I could state it in a sentence. My GTM was a vague intention to post somewhere. And my CFF was quietly broken, because CHF 4.50 makes the arithmetic fail no matter how good the other three corners are.
The diamond’s point is not that you need all four. It is that a weak corner is not a weak corner — it is a broken model. You cannot compensate for an impossible cash flow formula with an excellent operating model. I had been optimising the corner I found most interesting.
Skok’s related heuristic is worth keeping next to it. He argues the products that spread are the ones that SLIP: Simple to use and install, Low to no initial cost, Instant and ongoing value, Plays well in the ecosystem. Read that list again and notice that three of the four are go-to-market properties expressed as product decisions. The framework refuses to let you separate what you build from how it reaches people.
Where this is going
This is the part that has stayed with me longest, and it is why I am writing it down.
Everything I found in those three weeks was findable. Every API restriction is published. Every regulatory chain is in the legal text. Every pricing trap is on a pricing page. None of it was secret. It was simply distributed across forty sources, in four languages, in documents nobody reads until the problem has already cost them something.
And the frameworks that would have caught the biggest mistake — the pricing one — are taught at Harvard and MIT and have been in the public domain for years. I knew they existed. I did not apply them, because when you are excited about an idea, you start with the part you enjoy.
So the natural next step, for me, is a platform where an idea gets challenged against predefined criteria before the work starts. Not a business plan generator — there are enough of those. Something that takes the context of a specific venture and systematically surfaces the risks, constraints and opportunities that founders reliably miss:
- Which of your assumed data sources are actually accessible, and under whose terms
- Which regulatory obligations your data model triggers, and which architecture choice removes them
- Where your infrastructure costs bend as you scale, and what a generic schema is worth
- Which steps run on a clock you do not control, such as a mandatory testing window before a store release
- And, before all of it, whether your Minimum Viable Segment actually overlaps in all five circles — including budget
That is the same instinct behind the AI Solutions Hub: the value was never in knowing something rare, it was in making dispersed knowledge decidable.
The learning nugget
I set out to answer how do I build this? and spent three weeks getting excellent answers.
The question I should have asked first was for whom, at what price, reached how? — because that answer would have changed the technology decisions, not the other way around.
The frameworks are free. The mistakes are not.