Our YC application, published before we know the answer

We applied to Y Combinator for the Winter 2027 batch. Below is most of what we wrote.

Read it as an example, not as advice. We might not get in. If we don't, this post stays up unchanged. That is why I am posting it now instead of waiting. Almost every application you can read online was posted by someone who got in. By then the writer knows which answers worked, and rewrites the story around them. Nobody posts the one that was rejected. So you only get to learn from the winners. I don't know yet which one this is.

I've marked the answers I think are weak. Those marks are the useful part. If you are filling in the same form this month, skip the parts about our company and read the criticism.

Two sections are missing. The equity breakdown is out, because it contains advisor stakes and vesting terms for people who didn't sign up to have their percentage on a public page. The balance sheet is out too: the bank balance, the runway, and what we have raised. We are fundraising. Those numbers are a negotiating position, not a lesson anyone can use. Revenue and the pivot that failed are both here.

The two videos

YC asks for a one-minute founder video and a demo. Both are below, as submitted.

The founder video is the three of us on a call, recorded in one take. Michele is in Piedmont, Teppo and I are in Helsinki, which is the company as it actually works rather than a set.

The demo is Teppo asking Skene a question a growth team would ask, "calculate the purchase_completed costs", and Skene answering that it cannot, because the event is not tracked. It then opens a pull request that adds the event. That is the product in twenty-six seconds, and it is the honest version: the interesting part is the answer we cannot give yet.

The address bar is blurred. The recording was made against a local build and the URL carried a session token.

What we told them we do

The fifty character version: turns GTM plans into event tracking and experiments. The long version is where the word count went.

Almost 1B commits were pushed to Github in 2025 and every commit can break the lines that record a signup, activation or campaign tracking. GTM teams work depend on that code and cannot run enough experiments, because they do not know if the data to prove the experiment exists. Skene closes the gap. GTM can turn the plans and campaigns into which event should be tracked to prove what works, and generate new experiments with our agents. The product checks that engineering has implemented the plans correctly (or we create a PR), reviews future PRs to make sure the tracking doesn't break with product updates, generates fixes if it does, and then runs experiments for GTM based on learnings.

The weak part is the first sentence. A billion commits is a big number about the world, not about us. Anyone who has been pitched before will skip past it. I wrote it because the answer felt like it needed a run-up. That instinct is what produces bad first sentences. The second sentence is the one that does the work, and it should have gone first.

So check your own first sentence. Does it say something, or is it just clearing your throat?

The numbers, unrounded

First revenue was June 2026. We are at roughly 24,000 USD ARR. Customers pay between 35 and 249 USD a month.

All three founders have been full-time since 1 September 2025. Teppo and Michele and I write code, and two part-time engineers work with us on product.

We wrote the numbers plainly and did not work out a growth rate. A percentage off a base this small tells you more about the base than about the growth, and the reader knows it. If your numbers are small, say the small number. It reads better than a big percentage.

The pivot, which we could have hidden and didn't

We launched our first MVP in late 2025, then pivoted in January 2026 from traditional SaaS code-to-lifecycle automation to an open-source scanner with a TUI. The open-source tool reached roughly 1,000 unique clones per month, but that adoption didn't convert into cloud usage.

That sentence covers four months we are not getting back. The open source tool worked. A thousand developers a month cloned it, and almost none of them paid us anything. We had built for someone who was never going to buy. A developer will happily run a free scanner on their own code. They will not put a subscription on the company card for it. And they are not the person whose quarter depends on knowing whether the pricing test worked.

The tool is still published and still maintained. What changed in May 2026 was who we sell to, not what we ship.

I think this is the answer that gives us the best chance, and I was still tempted to soften it. If you have a failure like this, write it flat. Hedged writing about a pivot reads worse than the pivot.

Techstars, 2017, and what an accelerator is actually for

I've been through one of these before. In 2017 GetJenny applied to Techstars, went to the finals in London, got cut, and was then offered a place in Tel Aviv. We took it.

It was a good experience and the value was almost entirely people. Greg Rogers and Chris Adelsbach, and alumni like Ben from Kard, are contacts I still have nine years later. The programme content mattered less than the room it put me in.

What I got wrong was expecting the programme to tell me what to build. It can't, and that isn't what it is for. It makes whatever you bring with you bigger. Bring nothing real and you waste three months. That is the honest reason we applied now and not a year ago. It is also why the application says we would move the company to New York afterwards. Our customers are there. We are in Helsinki. Being in the same city is the one thing money can't buy.

So if you are thinking about an accelerator, answer this first. What would you bring into the room? And does it get bigger by being there?

The bet we described under "other ideas you considered"

The application asks what else you thought about applying with. It notes that this is sometimes the answer they fund. Ours was self-maintaining APIs, which is close to what we already do. The observation under it is the one our distribution rests on. An API from a company like Supabase rarely breaks. That doesn't stop a developer, or a coding agent, from breaking the connection at their end.

The decision behind it is to support one database really well before supporting all of them. For us that database is Supabase. Supabase went through YC themselves, which I would rather say than pretend I hadn't noticed. That isn't the reason. The reason is that the data we need already sits in a Postgres database, and we can read its shape without asking anyone to move anything.

Write down what a bet like this costs you, before someone asks about it in an interview. Ours means we only reach companies on one database. Those companies may turn out to be smaller and younger than the ones that can pay us. If so, we will have spent a year reaching people who were never going to fund us. We would find out slowly, because small customers leave quietly.

The market answer, where I built the number wrong

We sell subscriptions starting from $249/month. We estimate that there is 30,000 funded B2B SaaS companies that have separate growth and engineering teams. At today's Pro price that is a $90M market. Looking at other GTM stack companies such as Clay at the $10K-30K per-account platform pricing we are building toward it is a $300M-1B a year business. Near term: €1M ARR within 18 months.

The arithmetic holds up. 30,000 companies times $249 a month is $89.6M, and both inputs are on the page, so you can attack either one without taking a spreadsheet apart first.

The mistake is that I led with it. $90M is the size of the market if we won every company in it, and nobody wins every company. At a real share of ten percent the same sum says we are a $9M business. So the number I called defensible is the number that argues against us, and I put it first.

The fault is in what I multiplied by. $249 is our entry price this week. It is not what the job is worth. Clay is paid $10,000 to $30,000 per account for work that sits in the same daily routine as this. Run the same 30,000 companies at $15,000 and you get $450M, using our own count and a real price somebody already pays.

That is the answer I should have written. Same count, same method, priced at what the work is worth instead of what our pricing page says today.

The note for anyone writing this answer. Check what your market number is multiplied by. If it is your current list price, you have not sized a market, you have sized your pricing page. Both numbers can be honest and only one of them makes your case.

Two questions, and then the outcome

We picked the wrong customer once already. It took a thousand cloners and four months to find out. So the first question is whether we've done it again. Is a GTM team the right buyer here? Or is the person who really feels the pain still an engineer who can't get anyone to prioritise fixing the tracking? If you have watched this go one way or the other inside a company, I want to hear it.

Second, for anyone who has written one of these that got in: what would you cut? Not what to add. The application is long and I suspect two of the answers above are doing no work at all.

Write to me at teemu@skene.ai or on LinkedIn. And if you are mid-application right now and want a second pair of eyes on yours, send it over. I'm not qualified to tell you it will work, but I'll tell you which sentence I'd delete.

I'll post the result here whichever way it goes.