Now

What it is & why

This isn't a post about code. It's about how, instead of a backend, I'm building unit economics — instead of APIs, sublease agreements — and instead of a staging environment, actual square meters. But the principle is the same: I'm assembling a system out of independent modules that each have to work on their own AND together.

THE HIDEOUT is a men’s club on roughly 300 sqm, where a retro-and-esports gaming lounge, a billiards hall, a barbershop, and a bar all live under one roof. The idea is simple: usually each of these businesses fights alone for foot traffic. I’m building one continuous "evening route" instead — show up to game with friends → move to billiards → get a haircut → close out the night at the bar. Traffic flows organically from one module to the next.

The problem I fought

How do you package four separate businesses into one structure without exposing the parent company to financial risk? Each vertical is its own legal entity (the bar even has its own separate investor, since grant funding doesn’t cover alcohol). All of them sublease space from the parent company, which holds the master lease. Split the sublease "by eye," and the base entity easily ends up covering shared-area costs — hallways, restrooms, the lounge — out of its own pocket.

I had to build an actual formula: I took the base rent (~$2,500/month) and split it not by raw square meters but by "effective area," factoring in each unit’s share of common space (a 1.357 coefficient). Result: everyone pays the same rate, and the combined sublease covers the base with a small margin. The core unit never runs at a loss.

The second snag was proving the traffic story to investors. "There’ll be synergy" doesn’t fly. I built an actual funnel: out of 1,100 gamers a month (at 30% utilization), how many realistically move on to billiards (15%) and the barbershop (8%), and how many land in the bar (45%). That’s what the hard P&L came from.

Under the hood (business architecture)

• Structure: 4 verticals, separate P&L each, one shared traffic flow
• Capital: ~$97,000 (grants, founders’ own funds, external investment into the bar)
• Payback: ~1.5 years in the base scenario (consolidated EBITDA ~$5,000/month)
• Redundancy: shared backup generator + UPS for the whole complex, separate reserve funds per unit

Behind the scenes — where I am and what I’ve stepped on

Stage: "looks perfect on paper, no signatures yet." Business plans are finished, I’m hunting for the right 300 sqm space, and I’m in talks with the bar’s investor and suppliers.

The biggest headaches have been timing and paperwork. Grant program terms shifted mid-application, and I had to rewrite submissions on the fly. Syncing three independent business plans so the traffic and rent numbers match down to the cent has been its own kind of pain — any mismatch is an instant red flag for a grant committee.

What’s next

• Submit grant applications
• Wait for approval, sign the lease, start renovating shared areas
• Funding tranches, equipment purchases, hiring
• Soft launch, alcohol licensing, official opening with a Twitch tournament

What it is & why

Bisi is an iOS app for tracking home maintenance and repairs. See a crack in the tile? Snap a photo, create a task. Fix it? Snap an "after" photo, the task closes, you get XP. The idea came from a plain pain point: in every home, the "what’s broken" list lives in chaos — scattered across chats, notes apps, or just somebody’s memory. Nobody remembers who spotted the leak or whether it actually got fixed. Bisi is a household-maintenance tracker with proof — before/after photos — that turns the chore into a game.

The problem I fought

I decided to build it offline-first. A user should be able to create a task with zero internet, and have the data sync up later. Sounds great on paper. Breaks in painful ways in practice.

Symptom 1 — the infinite spinner. Turns out in Firebase, `try await ref.setData(...)` only resolves once the server confirms the write. Offline, the user got stuck on an endless loading spinner, even though the data had already landed locally.

Symptom 2 — vanishing tasks. A home would get created offline, and the "broken thing" photo would sometimes reach the server before the home document itself did. Storage security rules looked for the home, didn’t find it, and threw a 403. That’s where I fell into a Swift trap: the `localizedDescription` property just printed an error code. I mistook "unauthorized" for "unauthenticated" and burned an entire session debugging auth, before I thought to print the raw `String(describing:)` instead. Turned out it wasn’t "no permission" — it was "hang on, the document hasn’t landed yet."

Under the hood (stack)

• Client: iOS / SwiftUI
• Backend: Firebase (Firestore, Auth via OTP + Apple, Storage)
• Logic: Cloud Functions (13 of them — invites, cascading deletes, orphaned-file cleanup)
• Architecture: offline-first. Retry queue with 10 attempts (~2.5 minutes of sync waiting), local writes that never block the UI

Behind the scenes — where I’m actually stuck

Honestly — right now I’m fighting my own file system more than my code. I moved the project to a new folder and nearly deleted the `.xcodeproj` itself, mistaking it for a duplicate (the extension had gotten stripped). Lost part of the backend, the Firestore rules, and the git history in the process. New personal rule: what looks like junk might be your only backup.

Right now I’m rebuilding a Frankenstein out of the freshest surviving pieces. On the product side, the core flow — login → create home → task → "after" photo → XP — works. But there are some real holes.

What’s next

• Hotfixes: fix home invites (the "share" sheet just goes silent) and Gmail OTP login (a second user literally can’t get in). Add account deletion — Apple won’t approve the app store listing without it
• Refactor: `DashboardView.swift` has ballooned to 35 KB and is painful to work in — breaking it into components
• UI/UX: polish the login screen, build a proper dashboard grid, and nail the emotional centerpiece — a nice before/after photo comparison slider
• Backlog: localization, push notifications, Sentry, StoreKit 2 subscriptions, and — finally — tests. Currently sitting at zero.

What it is & why I started it

Seika is a task tracker with a task tree that lives entirely inside Telegram as a Mini App. No separate website, no logins, no passwords. The idea came out of a plain annoyance: my team already lives in Telegram all day — chats, calls, files — but to assign a task, we had to jump into Notion or Trello. That’s one extra tab and one extra "yeah, I’ll add it later." Half our agreements just quietly died in the chat history. I wanted to assign tasks the human way: type or voice-message the AI what needs doing, and let it break it down into a tree — goal → subtasks → owners → deadlines.

The problem I actually fought

The first version worked the naive way: the AI parsed a project and created tasks one at a time, through separate model calls. Worked great — until someone dropped a project with dozens of tasks at once. That’s when I hit the wall: my free Gemini quota ran out mid-job, because every single step was its own trip to the model. I had to split the architecture into two layers:

1. Planner (AI): a single heavy call reads the entire prompt and returns a complete JSON tree structure.
2. Executor (code): plain logic, no model involved, takes that plan and writes it to the database, checking limits along the way (depth, subtask count). Funny how "don’t send an expensive LLM back and forth to do mechanical work" only looks obvious in hindsight.

The bug that cost the most time

There was also a nasty visual bug: I taught the tree to branch out horizontally, but every screenshot still showed a perfectly straight vertical line. I burned a lot of time debugging the connections before realizing the tree was rendering from the left edge instead of the center. Only found it by running the algorithm by hand, on paper.

Under the hood (stack)

• Backend: Node.js + TypeScript, Express, Telegraf
• Database: deliberately none. Flat JSON files with atomic writes. For "a team, not thousands of tenants" scale, it’s cheaper to maintain — and you can literally read the database with your own eyes
• AI: Google Gemini over raw REST (no heavy SDK), with my own retry logic
• Frontend: plain JS/HTML/CSS, no frameworks, no build step. The tree is hand-drawn in SVG with honest centering
• Deploy: PM2 on a plain VPS + Cloudflare Tunnel

Behind the scenes — where I am now

There are now hard limits on tree depth (so it can’t spiral into a monster), bulk voice upload, and — the important one — actual personal pings in Telegram when a task gets assigned (before, people only found out about tasks by opening the app, which was a real source of frustration). Before every deploy I run 80+ regression tests — I once caught a bug in Telegram signature verification that cost me several hours and taught me the lesson properly.

What’s next

Packaging it for the App Store is on the back burner. Right now the real goal is getting Seika into 10 real Telegram-based teams and seeing how it holds up in someone else’s hands. I don’t want to rush a pretty wrapper before the core is actually battle-tested.

What it is & why

I’m building underdogdiary.com — a personal hub for my own brand. Not a typical info-business landing page, but a full multi-page site (Now, Notes, Essays, a page for the book). I spent 10 years grinding in retail, went through a real crisis, and threw myself headfirst into AI. This site is the diary of someone closing a skills gap in public, in real time. There was an earlier placeholder attempt — I killed it. The copy was fine, but the visuals didn’t carry the story. Building from zero now.

The problem I fought

I wanted two things that fight each other:

1. A heavy 3D scene. Not the generic "neural sphere reacting to your cursor" cliché — an actual camera dive through water, past wreckage, gears, and blueprints, in an engraving/etching art style.
2. A light, fast mobile site. Most of my traffic will come from TikTok and Instagram. A genuine 3D scene with a hatching shader would kill a phone on 4G.

How I got out of it

I stopped trying to fit an elephant into a suitcase. Instead of heavy 3D geometry, I use flat illustrated PNG sprites placed in 3D space. That gets 90% of the visual effect without overloading the renderer. And on mobile, the 3D scene doesn’t load at all — a clean static fallback takes its place instead. Blunt, but honest.

Under the hood (stack)

• Build: Next.js + MDX + Tailwind. I write posts in markup but embed React components directly in the text (no headless CMS — I’m the only one writing content, I don’t need an extra subscription layer)
• Interactivity: Three.js + GSAP/ScrollTrigger + Lenis (scroll = depth of the dive)
• Infrastructure: Cloudflare (WAF/rate limiting on forms) + Beehiiv (double opt-in email)
• Visual direction: "Engraved Digital Garden" — dark navy background instead of generic black SaaS minimalism, cream engraving linework, bento cards

Behind the scenes — where I am

Honestly — not a single line of front-end code written yet. Sounds strange for a project update, but the foundation is poured:

• Domain bought and live on Cloudflare
• All 10 pages and the concept fully locked in. First wave of copy is written
• The "financial reckoning" block — my real numbers, real debt — is calculated but on hold. Not rushing the public breakdown
• Generated a first pass at a logo — a gamer-achievement-medallion style badge — still refining it. Warming up social accounts in parallel; the site isn’t blocking that, it just lives as a promise in the bio link for now

What’s next

• Finish the logo and the copy for the About and Uses sections
• Start coding the 3D scene from the locked concept
• Ship a first working deploy (even if static, with a working email form)
• Set up a cron job to pull short notes from Threads via the API

What it is & why

I’m building a price-intelligence platform — competitor price and promo monitoring for a large retail chain. The idea is simple: a buyer walks into a supplier negotiation and says "this item is 6% cheaper at a competitor." But they say it backed by a timestamped screenshot and a link, not a guess. The pain: right now, managers manually re-copy prices into spreadsheets once a week. It’s slow, subjective, and impossible to prove in a negotiation. There’s also a nastier trap: shrinkflation. 850ml of milk at one chain and 900ml at another, same shelf price, isn’t actually the same product. If the system doesn’t understand that, it just generates garbage.

The problem I actually fought

The nastiest bug showed up somewhere I wasn’t watching. A parser regex for prices above 1000 was truncating to the first three digits — parsing 1299 as 129. Worse: the health-check gate meant to catch exactly this kind of anomaly stayed silent. Why? Because the historical baseline had been built on the same corrupted data from day one. The system was comparing lies to lies and was perfectly happy with the result.

Second bug: the quality module required photo proof for ≥90% of tracked promos. The screenshot module wasn’t wired up yet. So every batch failed that check and quietly went into quarantine. From the outside, everything looked fine — scraper running, tests green. In reality, the product wasn’t producing a single row of dashboard data. I only found this by running a full audit and raising test coverage from 71 to 268 tests. Lesson: a demo running on synthetic data proves nothing.

There was also an architecture fight around AI. The spec wanted: "the model outputs a confidence score, anything below 98% gets reviewed by hand." I killed that idea. An LLM generates a confidence number the same way it generates any other token — it lies confidently on look-alike products. Instead, I built a conjunction of 7 hard Python rules, where the LLM’s contribution to the final score caps at 25%. In my architecture, the model is only ever allowed to veto a match — never approve one on its own.

Under the hood (stack)

Principle: no data beats wrong data.

• Core: Python 3.12 (async) + Pydantic v2 (validation at the very edge)
• Scraping: Playwright
• Queues: ARQ + Redis
• Databases: PostgreSQL 16 (ltree for categories, pg_trgm for search) as OLTP, ClickHouse as the OLAP layer — only ever sees clean, non-quarantined data
• Storage: MinIO/S3 (screenshots stored by SHA-256)
• Frontend/reporting: FastAPI + Power BI + openpyxl (auto-generated "negotiation packets" in Excel)

Where I am now and what’s next

The core works. 268 tests green. The system correctly handles shrinkflation and multi-packs ("2x115g"). Health gates genuinely catch promo failures and price spikes. During the audit I also found an old MVP dashboard sitting in the repo with a broken role system — a category manager could view other categories just by guessing an ID — and a JWT secret hardcoded into the source. Retired that code for good.

Next up: build the API for manual export of disputed price-matches and wire up Telegram alerts when a batch drops into quarantine. After that, waiting on client access to more retailers, collecting a clean baseline without publishing it yet, and calibrating the model. Long-term target: onboard a new data source in 3 days or less.

What it is & why

NODA is a distributed cold-storage and logistics network — not one giant central terminal, but several mid-sized hubs spread across different regions. Sounds like a standard business idea until you look at the market it’s entering: warehouse space is scarce, and cold-storage rental rates have climbed sharply in the past couple of years. That’s not "the market is growing" — that’s a market where supply is shrinking fast.

The problem I fought

There are two layers of pain here. Layer one is the business architecture itself. The classic approach — build one giant warehouse — is a serious single-point-of-failure risk. Any outage or disruption at one node takes down your entire chain. The fix is to build distributed, not centralized: a disruption at one small hub only stops that hub, not the whole business.

Layer two is my own mess with the investor numbers. When I sat down to build the financial model, some embarrassing stuff surfaced:

1. My first "buy land vs. lease" comparison came out suspiciously clean — identical totals over 10 years. Pretty, but wrong: I hadn’t accounted for notary fees, taxes, or realistic rate growth. Redid it honestly — buying is actually cheaper, but the numbers got messier and real.
2. My "worst case" scenario assumed zero growth in logistics rates. That was me lying to myself. In this market, logistics costs are going up no matter what. Had to rewrite the pessimistic case to reflect reality instead of my own wishful thinking about stability.
3. Formatting the investor document. Tables kept breaking apart in Word. Had to go under the hood with OOXML (python-docx) to hard-lock page breaks and structure. The document grew from 25 sprawling, messy pages into 39 perfectly structured ones — and that’s a win, not a bug.

Under the hood (structure — concrete and contracts)

• Infrastructure: modular warehouses with 2 zones (0…+4°C and −18°C freezer). Freezer-only warehouses are too narrow for this market
• Transport: used 1–2 ton refrigerated trucks. Deliberately not burning capital on new vehicles this early
• Business model: long-term contracts with a security deposit
• Phase B (scale): franchising, McDonald’s-style. NODA owns the land and the brand, franchisees pay royalties — lets the business grow without inflating its own CAPEX

Where I am now and what’s next

Concrete isn’t poured yet — we’re at the "investor-ready package" stage. A full investment plan is done, including the franchise phase and three honest payback scenarios. Also mapped out available financing and grant support.

But I’m not hiding the risks:

1. Legal status of the land for the first hub isn’t finalized yet — if that drags, the build timeline slips with it
2. The transport numbers in the model are working estimates, not signed contracts
3. An asset a partner is contributing (valued at several million) is currently just his asking price — waiting on an independent appraisal that could move the deal either direction

Next steps

Audit the partner’s asset, close out the land designation question, and start the investor negotiation round. From here, it’s driven by facts, not by the plan.