All posts

· 6 min read · By

Building what's NEXT

Why six side products share one suffix, how they sit on one foundation, and what this blog is for.

I manage engineering teams by day. After hours I design, build, and ship my own products: web apps, AI tools, and Telegram bots. Six of them are live right now, and every one carries the same suffix: NEXT.

I have shipped more than fifty products since 2010, most of them with teams, for clients. The NEXT products are different. They are the ones I own end to end, from the first commit to the production incident at midnight. This blog is about that second job.

Why one suffix

Naming is positioning. Each product answers the question "what comes next" in its own niche: NextWine finds your next bottle, NextLang builds your next flashcard deck, NextSpend tracks where the next paycheck goes, NextScalp surfaces the next trade worth a look. Once two products shared the pattern, keeping it became a rule, and the rule became a brand.

There is a quieter reason too. A shared suffix forces a shared bar. If an idea cannot earn the NEXT name, it does not ship. That single constraint has killed more weekend projects than any deadline ever did, and the survivors are better for it.

It also keeps me honest in code. The portfolio site treats the suffix as data, not decoration:

export type Project = {
  slug: string;
  name: `Next${string}`;
  tagline: string;
  stack: string[];
};

The template literal type Next${string} means the compiler rejects a product that breaks the naming rule. One typed module feeds the home page, the project pages, the sitemap, the RSS feed, and even the kinetic wordmark in the hero. Add a seventh product, and the whole site picks it up without a single layout change.

One foundation under all six

Six products in your spare time only works if you stop rebuilding the same plumbing. So the boring parts live in one place: NextRun, a Next.js 16 starter that ships authentication, Stripe payments with a credit system, a Telegram bot, a typed database layer, and a component library, wired together and tested.

Every new idea starts from that working foundation instead of a blank page. The first day goes to the part that is actually new, not to yet another login form. NextRun is itself one of the six, which means it gets battle-tested every time I start something.

The six, briefly

  • NextWine turns a curated catalog of 400+ wines into recommendations, through a taste quiz and free-text AI.
  • NextScalp watches every Binance perpetual in real time and sends only the few setups that pass a strict quality gate.
  • NextLang turns any text into ready-to-import flashcards for Quizlet, Anki, Mochi, and Brainscape, across 20+ languages.
  • NextSpend is a free expense tracker with multiple dashboards, shared family access, and six currencies.
  • NextDone gamifies chores inside a Telegram group with tasks, rewards, and an in-group shop.
  • NextRun is the template the other five stand on.

Three lean on AI. Two live entirely inside Telegram. All of them are real products with real users, not demos.

AI that earns its keep

The fastest way to ruin a product is to bolt AI onto everything. In the NEXT products, AI shows up only where it changes the answer: a free-text wine recommendation, a price-action read on a chart, a flashcard generated from a paragraph. Everywhere else, deterministic code wins because it is cheaper, faster, and predictable.

When AI does earn its place, it is metered. Credits, quotas, and rate limits are not an afterthought; they are what keeps a clever feature from becoming an unbounded bill. Picking the model is a product decision too: a cheaper tier for casual use, a stronger one when the stakes justify the cost.

Why Telegram is sometimes the better MVP

Two of the six are Telegram bots, and that is a deliberate choice, not a fallback. A bot skips the parts of a web app that slow you down at the start: no sign-up funnel, no responsive layout, no app store review. Your users are already in the app, notifications are free, and the conversation is the interface. For a tool that lives or dies on a daily habit, that is often the shortest path to finding out whether anyone actually wants it.

What managing teams taught me about shipping alone

The day job is leading engineering teams - over a hundred people across the years, a couple hundred technical interviews, and a long run of assessments and mentoring behind that. Less of it transfers to solo shipping than you would expect. Velocity does not. Process does not. What carries over is judgement about scope: knowing which 20% of an idea is the actual product, and having the nerve to cut the rest before it is built.

Managing also rewires how you treat your own time. With a team, the expensive mistake is a month of work pointed at the wrong problem, so you learn to kill that early - in a doc, before anyone writes code. Alone, the same instinct is the only thing between you and a graveyard of half-finished features. Every NEXT product is small on purpose, and the discipline that keeps it small is the one I spend the day job defending: a high bar, ruthless scoping, and the willingness to delete good work that has not earned its place. Building for yourself just removes everyone you could have blamed for not doing it.

Why a blog

The products are the proof, but the decisions behind them are invisible from the outside. Which parts of an AI feature deserve credits and rate limits. Why a Telegram bot is sometimes a better MVP than a web app. What a solo builder should automate first, and what is fine to do by hand. I keep answering these questions in private chats, so I might as well write them down once, properly.

There is a managing angle too. A lot of what makes these products ship is the same thing that makes a team ship: ruthless scoping, a high bar, and the discipline to delete. I expect those threads to cross here often.

What to expect

Occasional, practical, specific. No content calendar and no filler. Likely topics:

  • Next.js architecture that survives more than one product
  • AI features that earn their keep: credits, quotas, model selection
  • Telegram bots in production: payments, roles, cron jobs
  • Design systems for solo builders: one accent, strict rules
  • Lessons from managing teams that apply to shipping alone

If any of this is useful, the products live on the home page. If you want to talk, LinkedIn (opens in a new tab) is the fastest route.