Bet That Was on Your 2026 Bingo Card

I want to completely shed the notion that one should only post 'completed', 'successful', or 'useful' products because everything you build is worth sharing. These pieces may not work well, be pretty, or be useful, but I will write out my entire thought process around it and put a bow on whatever janky scraps I post so people can decide if it's worth using. I hope that these product memorial pieces create the jankiest of scrapyards possible--one that even I look back on bemused at the sheer volume of chaos

Bingo!

I've played bingo with my friends for years, but we've always had to manually create tiles and boards. I decided to make that into a multiplayer game.

The idea started years ago, but I first started developing systems probably 2 years ago.

Life It Lived

It was largely setup correctly in my mind. I pursued it as a 'service' not a 'subscription' app. So I would not have a true self-service portal or have subscribers, but rather pay per services rendered.

Cause of Death (As We Know It)

I tried to make those services entirely automated on my end which ended up being a big infrastructure project. What started as:

1. Get tiles from players
2. Create boards
3. Send boards

Turned into a multi-piece system using google sheets, forms, docs, etc. to onboard new players, manage the boards, and collect data and analytics.

If I wanted to, I could have done this with ZERO customer facing code until it got to a point where it was scaling faster than I could service! That's where I went wrong. I built something that would work for hundreds of transactions a month when I have zero.

I was smart and didn't build

1. Self Service
2. Self Checkout

However, I did attempt to build self onboard in that they could request a sign up sheet through the website, get an email back with payment information, pay, and then get an email with the game links -- all automatically. These are pseudo self service and self checkout automations.

What Remains Valuable

The architecture I used for it is largely useful. It is completely build in Google's ecosystem using app scripts, hooks, and their services. I think this is a REALLY strong position for a small service-based consultant/contract work to automate outputs; however, it can't come before a case-study and demand hypothesis.

Also, I learned a lot about AI coding and letting it run unsupervised. I was impressed how quickly this could build a scaled system for me once I knew what I wanted. This issue is that what I wanted was too big for what I needed.

How I’ll Honor It

I think I should rip it down and remake it as a bare minimum build. In any case, I think the lessons above can help, but I'm transaction based not customer based so I've remapped things to Games per Month. When that number gets too high, then I'll be up creek without a paddle.

Getting to 10 Games per Month

Closed private beta. Game are only created on the weekend. One page with marketing collateral. I'd mostly get customers from outbounds (friends, family, referrals). Subsidized costs with payment through Venmo.

Collect emails on google sheet for later.

What did I remove?

1. Public sign ups
2. Public onboarding
3. Public payments
4. Database (made it a spreadsheet)

What did I gain?

A system to build a case study out of.

Getting to 100 Games per Month

Single biggest bottlenecks from previous system?

If there is not a massive waitlist, then it's the marketing. If there is a massive waitlist, then get them off the waitlist and create games more often than the weekend.

1. Create a proper payment portal
2. Automatically create the game, but only 'unlock' it once payment is received (this unlock can be done by hand every morning).

All of this writing isn't giving me anything concrete to make sure I don't make the same mistake in the future. There is no one word or phrase that is coming to mind that can ensure I approach building with this mindset. If I had to pay myself per hour, then I probably be a lot stricter with what I build. I think that's too complex a system to think about because it would require estimated hours. I think a better way to right size things is to think of them in terms of a hackathon.

What can you build in 24 hours? If you haven't completed it by then, step back and rethink it. Either you should design it to be smaller or for a simpler use case.

Lessons

1. Turn all databases into spreadsheets*
2. Turn all 'sign ups' into Google form links*
3. Turn all websites into 'marketing power points' (not a literal power point, but pretty much just a slideshow website)
4. Turn all payment forms into 1 off links that you send
5. Do everything yourself by hand or with scripts

*Or justify why is NEED to be a DB and why you can't make money otherwise.