Interlude: The logo that took 1,000 tries

An interlude in the building in public series. The weekly diary picks up where week 7 left off; this one goes deep on a single subject.

When Philipp and I built Success.co we ran a design competition on 99designs, and we were genuinely happy with what came out of it. So this was not a leap into the dark. It is a known quantity: you get a hundred directions you would never have arrived at on your own, and if none of them land you have not spent a crazy amount of money. The downside is bounded and the upside is not, which is my favourite shape for a bet.

So I put an open brief on 99designs at the end of July with a real prize on it, and let it run for two weeks. Anyone could enter. By the time it closed there were 978 designs in there, from 41 designers watching the brief, across 64 messages and a couple of polls. I sat with a coffee most mornings and went through them in batches, and by the end my eye had gone completely numb.

The second one is the moment it turned into a real thing. I had picked a favourite and asked the designer to show me how it would look on a website, in an app and as a phone icon, in light and dark, before I committed. Which is how I ended up with the mockups further down this post.

What I was using before

Here is the mark I had been shipping with. I made it myself, in an afternoon, the way every logo I have ever made happened: open a design tool, ship whatever comes out, never look at it again.

It is fine. That is the whole problem with it. It is a rounded app tile with some dots joined together, which is what you get when a developer needs a logo by lunchtime and has decided not to think about it very hard. It says nothing about what the product does. It would sit unnoticed on any app store shelf in the world.

And here is what came out the far end of the competition.

A V built out of triangles, with the top left corner still coming together mid-flight. I liked it straight away, but it took me a couple of days to work out why. It reads as something assembling itself. That is literally the product. You describe a thing in a sentence and it assembles.

Picking it was a matter of whittling. Nine hundred and seventy eight entries down to a few dozen I would look at twice, then down to a shortlist of about ten, then down to three I kept coming back to over a couple of days, and finally down to one. Each round was harsher than the last, and the last one took the longest: by then everything left was good, and I was choosing between marks rather than eliminating mistakes.

The files arrived with a set of mockups, which I had not expected and enjoyed far more than I should have. Seeing a mark you have been squinting at as an SVG suddenly turned up on a t shirt, a phone home screen and a nav bar is the moment it stops being a shape and starts being a company.

The one that got me was the app icon sitting on a home screen between Calendar and Mail. That is the test, really. Not whether it looks good blown up on a presentation slide, but whether it holds at the size of a fingernail next to icons made by people with far bigger budgets than mine.

Then I had Claude animate it

Building in public is worthless if you only report the wins, so here is the unglamorous version of how the animation happened: I barely made it myself.

There was no commercial reason for it. Nobody asked. I just wanted the mark to move. What I did not do is sit down and hand animate an SVG for a day. I described what I wanted to Claude and kept it iterating. The order the fragments land in. Whether the big V draws itself or fades up. How much stagger before it stops reading as one motion and starts reading as noise. How long the whole thing runs before it becomes irritating on the fiftieth load, because I am the person who will see it more than anyone alive.

That last question is the one that took the passes. My job was to keep looking at it and saying not yet.

I did waste an hour before that. I tried ChatGPT on it first and it was useless, so I moved over to Claude and stopped fighting the tool.

Everything looks good once. Almost nothing looks good on the fiftieth viewing.

I think it is genuinely lovely, and the honest cost of it was an hour wasted on the wrong tool and then a run of iterations I mostly watched. It now runs on the boot splash and on the overlay while your app is generating, which means it appears at the two moments where somebody is waiting on us. If you have to make a person wait, at least give them something worth looking at.

Here it is doing its job, on the launchpad where every build starts:

The build: a website is a lot of website

The other thing that ate this fortnight was the marketing site, which I have been writing myself, page by page.

It is a home page, a pricing page, a product page, a features page, a security page, eleven pages for the different kinds of people who might use this, a template gallery, legal pages, and then the part that really gets you: thirty eight documentation articles and thirty six guides. Every one of those needs somebody to decide what it says.

The rule I write to is simple: if a page claims something, I go and check it in the codebase before it ships, and cut it back to what the code actually does today. This week that meant marking most of the integrations list as planned rather than live, because four of them are genuinely wired up and the rest are a roadmap I would like to have.

It is slower. It is the only version I can defend when somebody signs up and starts clicking.

There was never a day I sat down and wrote the website. I just keep iterating on it, over and over and over, every day.

The loop I have landed on keeps the site in step with the product. I plan a feature in Claude Cowork, thinking it through properly there before anything gets built. Then I get Cowork to write the prompt: one for Claude Code to go and build the feature, and a separate one to update the website for it. The feature and the page describing the feature get built from the same plan, so the site does not quietly drift a fortnight behind what the product actually does.

Company building: the hard thing about hard things

Here is the hard part of the fortnight.

I had two great guys lined up to come on this journey with me. We had agreed equity. We had sat through several meetings and worked out how it would run. Then, at the eleventh hour, both of them decided the project was too big and their heart was not in it.

No hard feelings, and I mean that. They are great guys and they were honest with me while being honest was still cheap. I will be supporting them in whatever they do next. Far better to hear it now than eighteen months down the line, with equity vesting and half a product built on the assumption they were there.

So I am doing everything. The builder, the sync work, the app, the website, the brand, the pricing, the testing marathons, the blog posts. All of it.

And yes, I am looking for people to join me. I am just wary of advertising for them. Partly because I have never found the best people that way; the ones I have loved working with came through people I already knew. Partly because it is early, the thing is not finished, and I would be asking somebody to take a real risk on a story rather than a product. And mostly, if I am honest, because hiring is a full time job in itself and I do not have a spare one right now. The build is moving faster than it ever has and I am cooking.

After a lot of back and forth I have made the call: I am setting up the new company and funding it myself, at least initially. My own money, on my own product, on my own timeline. That is not the plan I started the summer with. It is the plan that gets this built without waiting for anyone.

There is a version of that decision that reads as a setback. It does not feel like one.

Nobody is coming to build it for me. That turns out to be a schedule rather than a complaint.

Marketing: I would rather show than announce

The strategy for getting this in front of people is the same as the strategy for building it. Do the work in the open, show the real thing, and let the product do the talking.

That is why the demo on the site is a working app rather than a video, why the roadmap is public and you can vote on it, and why these posts include the days I wasted. Anyone can write a landing page that says the software is good. Very few people will put a live app on the page and invite you to click every button on it.

That is also why this blog exists, and why the diary goes back to week one rather than starting when there was something impressive to show. Building in public was a decision, not an accident: if the plan is to show the real thing instead of announcing it, the weeks it went badly have to be in there too.

I got lucky on the raw material. From the very start I had been keeping notes in the Journal app on my phone, mostly to stay sane and to be able to look back and see that the thing was actually moving on the days it did not feel like it. A daily record kept for your own head turns out to be exactly what you need when you decide to write the whole thing down in public.

I keep coming back to the line about how you should be embarrassed by your first version. I think what I have is already well past that. The part I want to be less embarrassed about is build quality and speed, and that is where the crazy amount of work is going. The goal is to be at least as good as the best app builders out there, people who are two years ahead of me with teams behind them, and I know exactly how that sounds. I love a challenge.

The only goal right now is to launch a product I am proud of.

Strategy: what I decided while staring at logos

A brand exercise sounds like the least important thing a one person company can be doing right now. It was not, because picking a mark forced me to answer questions I had been comfortably avoiding.

We do apps, and only apps. There is real pressure in this category to be everything at once: sites, landing pages, internal tools, documents, whatever the next demo demands. I would rather be the best in the world at one of those. Apps are also where the value compounds. A landing page is one build and you are done. A real application gets built over weeks and then extended for months, so it is both the hardest thing to do well and the thing worth doing well.

We own the backend. Most of this category rents its infrastructure from somebody else, which means renting somebody else's margin and inheriting somebody else's limits. The plan: start on Supabase for launch, then move to our own infrastructure after. Owning it is slower and harder, but it is the only version where the economics still work at scale, and the only version where I can tell you what your app costs to run without crossing my fingers.

No surprise bills, and no meanness with the free tier. The loudest complaint about tools in this space is running dry in the middle of a fix, or finding a bill you did not agree to. Both of those are choices somebody made. I would rather be generous at the top and honest about pricing than squeeze a few dollars out of somebody who is still deciding whether to trust us.

So I built a fix for the worst of it, and I have not seen it anywhere else in this category: Credit estimate mode. Before a prompt runs, it tells you roughly what that piece of work will cost in credits, and nothing is spent until you agree to it. The answer to a bill you did not sanction is not a better refunds policy. It is quoting the price before the work, the way every other trade on earth manages to.

Here it is on a real edit: the estimate, the credits you'd have left after, exactly which files the change touches, and an Approve button standing between the quote and the spend.

We do not stop when the app works. This is the one I care most about. Getting a working app on screen is where nearly everyone stops, and it is not where the customer stops. They did not want an app.

They wanted a business.

So we keep going: setting up your Stripe products and prices, wiring forms so enquiries land somewhere useful, domains, auth, roles and permissions, publishing. At every step the choice is to do the next thing for you or hand you a to do list, and we do the next thing. That is the extra mile, and it is the difference between a demo and something you can actually run a business on.

Why the unglamorous part comes first

The reason Vorx exists is VorxSync, our own sync engine. It is the thing I am genuinely excited about, it is years of work already proven in production, and it is why an app built here can feel instant, keep working with no connection, and stay live for everyone at once. That is the endgame.

But you do not get to the endgame by starting there. What I believe is that we have to nail standard apps first: the ordinary server-backed build, the kind every tool in this category produces, before we move on to the accelerated ones. Put the sync engine under an app that is not excellent and instant, offline and realtime are just adjectives attached to something nobody wants. So the current phase is the unglamorous one: make the standard app build brilliantly, every time, for every prompt. That is why last week was 188 test builds and a defect ledger, and why this week was teaching the builder to stop inventing statistics in your app's copy.

Where it ends up is Vorx Apps. That is the goal, and it is what the sync engine is for. It will be a choice rather than something imposed on you, though: build the standard version or the accelerated one, with demos that run the same app both ways so you can feel the difference instead of taking my word for it.

Get that right and the sync engine turns a great app into one that feels alive. Get it wrong and the sync engine is a very sophisticated way to keep a mediocre app in sync.

So: new logo, whittled down out of a thousand. An animated version of it I did not have to draw by hand. A company to set up, on my own money, on my own. Back to the build pipeline.

Peter