Skip to content
~/ tommybuilt .dev

// the journey

The Journey.

There was no clean startup thesis at the start of this. There were a few domain names, some half-built websites, a handful of AI tools, and a stubborn belief that if I kept shipping, one of them would eventually stick.

Here is how it actually went. Website builders to a real product stack, a pile of unrelated sites to something that works like a company. Some of it worked. Some of it broke in ways I had coming. Some of it I shut off and walked away from.

Nine chapters, roughly in order, though the back half overlaps hard, because for a while I was building most of it at the same time.

  1. 01 Domains and Hunches
  2. 02 A Comment Box Becomes a Server
  3. 03 Learning to Build Like an Owner
  4. 04 Directories, Search, and the Traffic Engine
  5. 05 Building Things People Come Back To
  6. 06 Most of It Will Not Work
  7. 07 TextSpeakPro, and the Day Billing Became Real
  8. 08 One Founder, a Repeatable Machine
  9. 09 Building for Other People

// era 01 / before the stack / roughly 2022 to 2024

Domains and Hunches

TPS Worldwide LLC was filed in the USA in 2022, before there was a portfolio for it to hold. For a while the company was mostly a name and an idea, that if I kept putting things on the internet, eventually one of them would matter.

The early work was all website builders. Hostinger first, then Hostinger Horizons, their AI builder. Nobody was handing out architecture awards and I was not chasing one. The whole goal was to find out whether an idea could look like something real, fast. A page could exist in an afternoon. A rough concept could get a homepage, a headline, a logo. That speed taught me the habit I still lean on hardest: do not talk about the idea, ship a version of it and look at it.

A couple of ideas from this period are still alive today. The first rough versions of what became ClickSolveTools, a free browser tools site, and VideoGameCentral, a gaming content site, both started here as experiments long before they were rebuilt properly. At the time they were just me poking at things to see what stuck. That is the honest description of this whole era. There was no plan, just a lot of poking.

The first time I touched a real codebase was 2024, a SvelteKit app I built with a collaborator. It never became a business. What it did was show me the other side of a website builder for the first time: actual code, actual version history, actual control.

The builders had a ceiling. The moment an idea needed real data, real accounts, real payment logic, or clean ownership of its own code, the limits showed up fast. That ceiling is what pushed everything that came next.

// era 02 / the first backend / early to mid 2025

A Comment Box Becomes a Server

In April 2025 I built something small that turned into a turning point, a comment widget for a blog. The first version was front-end only. Comments lived in the browser's local storage and went absolutely nowhere. Barely a real system. It still worked well enough to prove a principle I build on to this day: a feature does not have to be perfect to be useful.

Then I made it serious. The comment system moved onto Cloudflare Workers and a D1 database, with an admin approval step so nothing went public without a check. It grew into a whole little fleet of Workers. One to write comments, one to read them, one for likes, one for admin, one for approval.

That was the jump. On one side, static pages and front-end tricks. On the other, real application architecture. Suddenly I was thinking about things a page never makes you think about. Could someone spam this endpoint. What happens when the database gets hammered. What the free tier actually covers before it quietly starts failing.

It was nine days of hard work and then I left it alone for good. It was also the first project where I stopped arranging pages and started building backends.

// era 03 / the toolmaker / mid 2025

Learning to Build Like an Owner

Once I knew useful software could start simple, I leaned into small tools. A brandable invoice generator with editable line items, tax math, and PDF export, then persistence, multiple currencies, auto-save. A lightweight CRM, a contact manager with tags, filters, import and export, starred contacts, follow-up reminders. A site chatbot that started as a front-end pop-up with canned answers and grew into something that could actually answer from a site's own content.

None of these were big. That was the point. Each one followed the same shape: start with a simple utility, make it usable, add persistence, add import and export, then decide later whether it deserved accounts and a backend.

The change in this stretch was in the questions I asked. I stopped asking "can I build this" and started asking what an owner asks. Who is this for. What is the first useful thing it does. What does the homepage need to do in the first three seconds. What can stay manual for now. What can wait.

That shift, from builder to product owner, is the real skill. I do not hand-write most of the code and never have. What I got good at was describing exactly what a thing should do, precisely enough that an agent could execute it, and knowing what to leave out. The tools stayed small. The habit got big.

// era 04 / the surge / early 2026 through spring

Directories, Search, and the Traffic Engine

The beginning of 2026 is when it stopped being occasional and went relentless. Over about thirteen weeks I pushed more than 1,600 commits across more than a dozen projects. February alone was nearly 900. Most of that stretch ran through Cursor and Windsurf, the AI coding tools I lived in before Claude Code.

The projects that defined it were directories. GlowUpFinder, a beauty services discovery platform. BuilderAI.tools, a curated directory of open-source developer tools. ClickSolveTools, a site of free browser utilities that grew past three hundred of them. ReligionCompare, a citation-backed comparison site across two dozen traditions. Furford, a pet services directory.

Building all of them back to back taught me the single most useful strategy I have. I do not enjoy the social media grind and I am not good at pretending otherwise. So I build things people are already searching for: free tools, comparison pages, programmatic landing pages that each answer one specific query. Search does not sleep and it does not need me to post every day. A directory with the right pages keeps working long after I have moved on to the next thing.

That is the chapter where the portfolio stopped being a pile of sites and started being a strategy.

// era 05 / content and games / early to mid 2026

Building Things People Come Back To

Tools solve a problem and the user leaves. That is fine, that is the job. But around the same time I was building directories, I started a separate branch of the portfolio that scratched a different itch: things people come back to for their own sake.

MiniGamePlanet, a site of free browser games that grew past a hundred of them, with a coin economy, profiles, and an admin panel behind it. VideoGameCentral, a gaming news and content site. Jagan Worldwide Games as a brand for the game side, with a game foundation of its own.

This branch also taught me how much of building is branding, and how unglamorous that part is. I spent a genuinely surprising amount of time on logos and favicons. A mark can look great at full size and look like nothing as a sixteen-pixel browser-tab icon. One commit in this era stripped seven hundred and forty-eight em dashes out of a single site in one pass, which tells you about how much of this work is small, boring, and necessary.

A weak favicon makes a real project feel unfinished. A strong one makes a small project feel legit. Once you are running a portfolio, the logos stop being decoration and start being the trust layer, and I learned to treat them that way.

// era 06 / the cheap experiment / early 2026, roughly january to march

Most of It Will Not Work

Not every chapter is a build, and this one is the lesson sitting under all the others. Shipping a dozen things in three months taught me something fast, and a little brutally. Most of what I build will not work, and the whole strategy is built on expecting exactly that.

Some of the directories from that stretch are quietly pulling traffic today. Others I have not opened in months. A few I shut off entirely. Going in, I could not have told you which would be which. Nobody can pick the winner up front, so I stopped trying. The skill I actually needed was making each attempt cheap enough that being wrong barely cost me anything.

That is what the build system is really for. Every reused piece, every checklist I do not have to rewrite, every stack I already know cold, lowers the cost of one more swing. When a swing is cheap, you can afford a lot of them, and when you take a lot of them, you only need a few to land. The math only works if losing is cheap, so I spent that quarter getting very good at losing cheaply.

It also taught me to kill things without flinching. A project I have not opened in two months is just a browser tab I keep meaning to close. Archiving a dead idea used to feel like admitting failure. Now it mostly feels like clearing the desk for whatever is next, which is usually already sitting there waiting.

// era 07 / the first real saas / early 2026 onward

TextSpeakPro, and the Day Billing Became Real

TextSpeakPro is the project where I quit building things that look like products and built a real one.

It is an AI text-to-speech platform. You give it text, it gives you a voiceover you can download, and the better voices sit behind paid plans. Underneath that simple promise is the first system I built with every serious part wired up: accounts and auth, Stripe billing, usage metering, a tiered set of voices, legal and compliance pages, and a backend that abstracts the voice providers so the product never has to care which vendor is behind a given tier.

It was also where the difficulty jumped. Stripe alone was a fight: test mode versus the newer sandboxes, live and test data living in separate worlds, webhooks, a checkout redirect pointed at the wrong domain by one wrong environment variable. One audit finding I still think about: character usage had to be reserved before the provider call, or someone could run up real provider costs before the app ever deducted a credit. Billing logic is core infrastructure, and TextSpeakPro is where that stopped being theory and became something I had felt with my own hands.

It launched late one night at the end of February 2026. First signups, then first paying customers, and it has kept running as a real product ever since. That is the part I am proud of. It got found, used, and paid for, and then it kept getting found, used, and paid for, which is a completely different thing from having an idea.

// era 08 / the system / spring 2026

One Founder, a Repeatable Machine

By spring 2026 the portfolio needed structure, and TPS Worldwide finally became the umbrella it was filed to be back in 2022. A real home for the legal side, the contracts, the ownership lines, and the public face of a multi-project operation, instead of just a name on a form.

Underneath it, a build system had quietly emerged from doing the same things over and over. Every new project now starts the same way. Name it, choose the domain, define what the homepage promises in one line. Pick the framework by the job: content and SEO sites in Astro, apps with dashboards in SvelteKit, simple tools and games in plain HTML and JavaScript. Apply the same day-one checklist every time: canonical tags, sitemap, robots rules, security headers, structured data, the redirect from www to the bare domain. Add the legal pages. Add the SEO architecture before the content. Launch a basic but real version. Then, and only then, decide what deserves to be automated.

I also built TPS Command Center, a single Cloudflare Worker running a set of AI agents on cron schedules to handle recurring business tasks. The point of all of it is leverage. One person can run this many projects because almost nothing gets invented from scratch anymore. The stack is familiar, the checklist is fixed, and the next project starts halfway down the field.

// era 09 / now / may 2026

Building for Other People

By now this has stopped being a story about learning to code. It never really was one. What it is about is learning to build internet businesses with AI as the lever, and getting fast enough that the cost of trying just collapsed.

That speed is the whole point now, because today I take the same machine and point it at other people's problems. This is the work I actually want to be doing. Product development, websites and web services, the unglamorous infrastructure under a real product, the growth that comes after launch. For other people now, as the main work, with my own portfolio standing behind it as the proof.

Opal and Ore, an online store and brand for an independent artist, is what that looks like in practice. It is client work. I built it and I keep it running, the e-commerce, the payments, the admin, the infrastructure, while the artist runs the business on top. That is the model. Someone has an idea, or a product that needs to grow. I can name it, brand it, prototype it, deploy it, wire up payments, write the legal pages, build the SEO, and find out whether anyone cares. Fast, and solo.

This site, tommybuilt.dev, got built and deployed in a single sitting, which is either a good sign or an on-brand one.

I am not going to pretend everything worked. Most things in a portfolio this size will not. There have been broken deploys, confidently wrong AI code, Stripe screens that made no sense, migrations run against the wrong database, and more domains than any reasonable person should own. The wins are real too, and they keep growing. I shipped a SaaS, and it has paying customers and is still running. I built directories pulling steady, growing traffic. I built brands, tools, and games, and turned a pile of random ideas into something that works like a company.

The portfolio was always the proof. The job is helping other people build and grow theirs.

// next

The story is one thing. The proof is two more.

Want the receipts? The work is where the shipped products live. The blog is where the field notes go.