In a late night fever dream earlier this week, I made a last-minute decision to submit an application pitching swisbhook to Y Combinator’s 2025 spring batch. It’s highly unlikely that YC chooses to fund swishbook — fewer than 2% of companies that apply are accepted — but filling out the application was a good exercise in focusing my thinking. The core mentality I have now is: build fast, get feedback, repeat.

My goal has shifted to trying to get a super rudimentary alpha product launched by the end of March. After that, I’ll probably share the YC application in full detail.

Peeking behind the curtain

Last week, I alluded to what I have in my head for swishbook without really going into any detail. Here, I’ll step through the mechanics in slightly more detail, while keeping the secret sauce behind the curtain.

In short, swishbook is a platform that allows users to access (and, ideally, manipulate) the outputs of a suite of products serving inference and optimization. Under the hood, swishbook:

• scrapes some information off the internet

• fits a bayesian model to historical data

• predicts outcomes based on new data

• provides a recommended optimal decision based on those predictions

• serves the optimal decisions to users via a frontend UI

In short, swishbook is a super simple CRUD app — and really I plan for minimal user-initiated modifications to the underlying database. Even with the simplicity, however, there’s a lot of hurdles to tackle that, as a data scientist, feel foreign and new, like:

• building a modern frontend (javascript, ew!)

• handling user auth

• handling payments and product allocation

• connecting the frontend to the backend

Most of the backend problems feel very solvable to me. And I know the frontend problems are, because people set up sites with users and payments all the time. It’s just a matter of getting scrappy, figuring things out along the way, and getting things done.