A Telegram Bot Instead of SaaS: When a Simple Stack Is More Honest than Kubernetes — Three Working Bots, Real Numbers, Limits Author: Дністер Published: 2026-09-28T03:01:35.000Z Language: en URL: https://neurodrift.org/en/blog/telegram-boty-zamist-saas-mvp-yak-kostyl/ Original (Ukrainian): https://neurodrift.org/blog/telegram-boty-zamist-saas-mvp-yak-kostyl/ Tags: Telegram, bots, SaaS, MVP, product Original source: https://neurodrift.org/blog/telegram-boty-zamist-saas-mvp-yak-kostyl/ A founder's dissection: why SaaS overengineering is not an engineering disease but a psychological one. Real numbers (Standish, CB Insights, Dropbox, Telegram, Formula Bot), three of my own bots-as-crutches in production, and the honest price of speed. Scalpel, no anesthesia. ----- 2,048 words of memory that flew to the Moon On July 16, 1969, a computer launched from Cape Canaveral that today couldn't boot the preloader of your SaaS. The Apollo Guidance Computer: 2,048 words of erasable memory — roughly 4 kilobytes of what we now call RAM. Permanent storage: 36,864 words, about 72 kilobytes of ROM. The crystal ticked at 2.048 MHz, but the machine internally halved that and actually ran at 1.024 MHz. The program wasn't "flashed" into it: women weavers at the Raytheon factory hand-threaded wire through ferrite rings — wire through a ring means one, bypassing the ring means zero. Software stitched into copper with a needle. They called it core rope memory. That crutch carried three human beings across ~380,000 kilometers of vacuum and brought them back alive. On 4 kilobytes of RAM and memory that could be unraveled with pliers. No unit tests, no code review — just three people who couldn't be allowed to die, and so they weren't. Now open any seed-stage startup's job posting. Kubernetes. Microservices. Four layers of cache. Service mesh, observability stack, GraphQL federation. Why? To send the user a notification that says "you got a new like." They flew to the Moon on less than a modern app needs to blink a notification. And the funniest part: the astronauts made it, while most of those startups won't reach their first hundred paying customers. Because they weren't building a rocket. They were building the feeling of building a rocket. Carpentry has an old rule for this: measure twice, cut once. In SaaS, it's been inverted. Here they design the perfect router-and-dust-extraction workshop seven times — and the one time they actually need to cut a board for a client, everything gets deferred "until the infrastructure is right." A crutch is a rough stool knocked together with black screws: you can't hide the joints, there's no lacquer, but it holds the weight of a grown man today. A blueprint of a stool holds no weight at all — frame it in oak if you like. This disease isn't new, but in 2025 it got steroids. Vibe-coding and AI code generation have dropped the cost of writing boilerplate to zero — which means every "architectural" layer now costs fewer hours, but burns exactly as much runway, and the Architect can now raise his ornament three times as fast. Meanwhile, the VC market dried out after 2022: rounds on "let's build the right infra" no longer close — investors want paying customers, not clean diagrams. So 2025–2026 is the year the price of overengineering became lethal, and simultaneously the year there are more tools to do it with. Time to talk without anesthesia. I have been funding and building products for three years. I am the person who loves beautiful architecture before the first live user shows up. And this piece is partly a dissection of other people's corpses, partly a confession. Because my most expensive mistakes cost not money. They cost time — time I spent polishing what nobody had asked for. They flew to the Moon on 4 KB. And you can't blink a notification without a service mesh. The question isn't the hardware. The question is who you're actually proving your seriousness to. Meet the Architect of Future Scale In every team — and in every version of my own head at three in the morning — one character lives. I call him the Architect of Future Scale. He has no users yet, but he's already drawing a microservices diagram on the whiteboard "for the case of a million." His favorite phrase, which you've heard a hundred times and said yourself fifty: "but what if we blow up and it can't scale?" He's designing Kubernetes for an audience currently consisting of his mom and two friends from university. One of the friends already unsubscribed. The Architect hasn't noticed yet — he's choosing between Kafka and RabbitMQ for a message queue that doesn't exist, because there are zero messages. The queue is empty, but fault-tolerant. His real product is not an app. His real product is the feeling of his own seriousness. The architecture diagram on the whiteboard is not a user tool — it is his mirror. He looks at the diagram and sees not a system but himself: grown-up, competent, "a real company." The actual app is almost superfluous here — it ruins the purity of the diagram with bugs and requests from real people who want different features than the ones on the board. And here is the key point, the reason I'm describing him at all. The Architect despises the crutch not because the crutch doesn't work. He despises it precisely because the crutch works — and in doing so, exposes the fact that his entire architecture was ornament. The crutch shames him. The crutch is naked — you can see the joints, the tape, the wire. It doesn't let him feel serious. And so the Architect chooses to look rather than to work. Hold on to that word — "look." It will come back more than once, because it is the diagnosis. !The Architect in a fleece vest admires his own Kubernetes diagram on the wall like a mirror; through a door in the background a solo maker has already launched the notification bot… The Architect of Future Scale looks at the diagram and sees not a system but himself. Through the door, a small bot has already sent the very message for which they're designing a queue for messages that don't exist. Meanwhile a stag beetle is dragging a relay — because the relay needs to move, not be drawn. What an MVP actually is (not what you think) MVP is not "a small version of the product." That formulation is Eric Ries's, and it gets cut down to nothing recognizable. An MVP is the version that yields maximum validated learning about customers for minimum effort. Not a small product. An instrument for measuring reality. The canonical proof. On April 4, 2007, Drew Houston posted to Hacker News not Dropbox. He posted a three-minute video showing how Dropbox would work if it existed. The product didn't exist yet — there was a screencast and a voiceover. This is the carpenter's sketch test: a good carpenter doesn't saw up the oak until he's sketched on a scrap of paper whether the wardrobe will fit in the alcove. Houston sketched the wardrobe with a video — and went to see whether anyone would even walk over to measure. A year later that same sketch went viral: when the demo video hit Digg after the TechCrunch50 launch in autumn 2008, the waitlist jumped from ~5,000 to 75,000 people overnight. The team had hoped for 15,000. (The legend often attaches these numbers to the 2007 HN post — in reality that one gathered modest attention; the explosion came later, via Digg.) But the point isn't the date of the avalanche. The point is that the sketch existed before the boards. Think about the mechanics. Houston measured demand for a product that didn't exist. The entire "development" was a camera, a screen, his own voice; the most expensive resource he burned was one evening. The Architect of Future Scale in his place would have spent those same months on distributed file synchronization — and found out whether anyone needed it at all only after the oak was sawn up and the money was ash. Houston found out in a night. The difference between those two people is not talent. The difference is that one measured reality, while the other spent six months admiring his reflection in a diagram and calling it "laying the foundation." Dropbox proved its hypothesis not with code but with a three-minute video — a sketch of the wardrobe before the boards. Demand for a non-existent product was measured by a voiceover. That is an MVP: not a small product, but an instrument for measuring reality. The bill for wanting to look Now the numbers that hurt. In 2002, at the XP conference in Sardinia, Jim Johnson of the Standish Group put a study of real feature usage on the screen. 45% of features are used never. Another 19% — rarely. Together 64% of code is dead weight that someone wrote, tested, documented, and is still carrying. Always used: only 7%. Honesty is part of the voice, so upfront: the sample is tiny — four internal applications — and the original of that presentation has never been released publicly; the numbers live through retelling in respectable secondary sources, not a primary document. This is not a law of physics, it's an illustration. But even as an illustration it winds you, because anyone who has written software recognizes themselves. You know that feature. You fought it for a week. It was opened twice, both times by you, to check whether it worked. The carpenter puts it more simply. He doesn't cut sixteen drawers into a chest of drawers because "the client might need sixteen." He cuts three that the person will actually open, and doesn't plane thirteen coffins for socks nobody will ever reach. In software, those thirteen empty drawers are called "extensibility," entered into the roadmap, and used to justify a salary bump. And now where this leads. CB Insights in its updated post-mortem (431 venture-backed companies that died from 2023 onward) listed the causes of death. Top diagnosis: "ran out of money," 70%. But that's not a cause, it's a symptom — the last exhale. Root cause #2: poor product-market fit, 43%. Translation: they built the wrong thing. The money drained while the team polished the unwanted and waited for the market to change its mind. (Percentages add up past 100% because companies usually die from several bullets at once.) If you rewrote the typical epitaph honestly, it would read like this — in italics, on a small brass plaque: "Here lies a startup. It had Google-grade microservices and observability Google still dreams of. It had no customers. But everything under the hood was done right." The carpenter who survived leaves behind a stool someone sits on. The Architect leaves behind a flawless blueprint for a stool and a bill for the timber. Put the two numbers in a single sentence. 64% of features nobody touches. 43% of companies die because they built the wrong thing. That is the same bill, presented twice — the bill for wanting to look rather than to work. And who is sitting at the startup's bedside while it bleeds out toward that 70%? The Architect. He won't kill the project — "we've put so much in." He'll keep the corpse on life support until the lights get cut for nonpayment, and call it "we haven't launched yet." Borrowed capital: why a bot is not poverty but leverage Now about the crutch specifically. The Telegram Bot API has been free since it launched in 2015. No subscription. No per-message fee. No limit on the number of bots. Default: 30 messages per second for broadcasts. Want more — Paid Broadcasts via @BotFather raises that to 1,000/sec at 0.1 Stars per message above the free threshold (and you pay only for delivered messages). But you hit that limit when you already have hundreds of thousands of active users — meaning it's a problem you want to have. What this means engineerically. The messenger has already built for you: billing, authorization, push notifications, mobile clients for iOS, Android, and web, cross-device sync, transport encryption, offline delivery. Everything the Architect of Future Scale wants to spend your next six months on — already exists. Ready. Given away for free. Building your own SaaS frontend on top of all this is like renting a fully equipped factory and then starting by tearing off the roof to relay it "correctly." The Toyota principle, the same idea as Ries's Build-Measure-Learn: don't produce what demand isn't pulling. Telegram handed you a factory. The Architect wants to rebuild it because someone else's roof offends his sense of beauty. And so you don't think this is philosophy for the broke: David Bressler, a data analyst without programming experience, went on parental leave in 2023 for six weeks. Over a weekend he assembled a basic MVP on the no-code platform Bubble.io: type in plain English what you need, get a ready Excel formula or SQL. He learned from YouTube, with an infant in his arms. After Product Hunt: $30,000 in revenue in three months. At the beginning of that growth the tool was holding ~$3–4k in monthly recurring revenue, and eventually grew to roughly a million users. Backend and frontend: entirely Bubble plus Stripe. No "real" code. A crutch assembled by one person over a weekend between feedings outpaced "proper" SaaS teams with their two thousand hours of development. While they were choosing a message queue, he was already counting revenue. The Architect is still choosing a message queue. Telegram handed you a factory with billing, authorization, and push baked in. Building your own SaaS on top is tearing off a perfectly good roof because someone else's offends your sense of beauty. My three crutches (from my own archive) Now my stake, no anesthesia. I have three Telegram bots running in production, and none of them has a SaaS face. The numbers below are from my own working archive — they can't be verified externally; I own them. PanicRadar. Assembled over a weekend. One VPS, infrastructure cost at the level of two coffees a month. I wanted to monitor certain signals and get pinged on my phone. The Architect in my head demanded a dashboard, charts, user roles, CSV export. I sent myself a message saying "new signal" in Telegram and closed the laptop. It still runs. There is no dashboard and there won't be, because I never wanted to look at a chart — I wanted to know when something was on fire, not admire a pretty curve of how it burned. NewsHarvest. A collector and distiller of the news stream. Here the Architect took his revenge: I started the first version "properly," with queues and workers. I spent a week on infrastructure for a load that didn't exist. Then I threw it out and rewrote it as a single script with a cron job. It runs more stably than the "correct" version, because there's nothing in it to break. That week was tribute to my own vanity. From my own archive (not externally verifiable), but I remember that week physically. Investigation bot. The dirtiest and the most useful. A handmade tool for specific investigative tasks. It looks inside like a garage after a hurricane. It does exactly what's needed and nothing more. No one besides those who need it will ever see it — and that's precisely why it needs no face. There's no one to be ashamed in front of, so it simply works. What all three have in common: each can be killed in five minutes and I won't cry over it. That is antifragility in Taleb's sense — cheap, disposable, mutates fast. You don't mind killing a crutch. But an expensive SaaS you mind killing even when the market has already said "no" — and it's precisely the sunk cost that keeps the corpse on life support. Apollo 13, a shotgun, and a hood on a rope Three scenes, because abstraction without a body is also ornament. But first a fourth, from my own workshop. Two carpenters need to deliver a batch of chairs by morning. The first picks up a chisel, glue, and a clamp — cuts by hand, mortise-and-tenon joints, because they hold without a single nail and need no calibration. The second powers up the CNC router and starts writing a cutting program "so it's finally done right." At dawn the first has delivered the batch and is drinking coffee. The second is still calibrating the feed rate. The program will be flawless, no doubt — for an order the neighbor already picked up. Scene one. April 1970, aboard Apollo 13, on the ground — a room full of NASA engineers. CO2 levels are rising on the damaged spacecraft; the crew is slowly suffocating. The square filter from the command module doesn't fit the round hole of the rescue module. The engineers dump a pile of junk on the table — exactly what the astronauts have on board: a hose, tape, the cover of a flight log, a sock. And someone says: we need to fit THIS into the hole of THAT using only THIS. They assembled a makeshift adapter from tape and cardboard. Three people kept breathing. The takeaway after the scene: the MVP is tape around a CO2 filter, not a showroom. What saves lives is not the beauty of the solution. What saves lives is that it flew in time. No Architect would have drawn that adapter on the whiteboard — it's embarrassing. Breathing through it isn't. !NASA engineers hand-assembling a CO2 filter adapter from tape, a hose, and a sock; through a glass partition, suited figures present an investment deck to an… Left of the glass, three people stay alive on tape and cardboard. Right, through the glass, suits applaud a slide for a product that doesn't exist. The crutch is shameful right up until the moment it gets you there. The stag beetle drags a crumb up the shelf — ungainly, but it delivers. Scene two. Terminator 2, the psychiatric ward breakout. T-1000 is right behind, seconds count. The T-800 doesn't look for the ideal weapon — he grabs the nearest shotgun and someone else's motorcycle, because they're here and they work now. A founder on the last of his runway is that same frame. The perfect tech stack waits for you in the showroom. But the pursuer — burning money — doesn't stand in line and doesn't cross-reference your architecture diagram. You grab the crutch and ride. Scene three, domestic. A mechanic drives his car holding the hood down by hand because the hinge is broken but the engine already runs. The neighbor laughs at the rope instead of a hinge. The car reaches town first. The crutch is shameful right up until the moment it gets you there. One second later it's no longer a crutch — it's the solution that worked. The neighbor is still standing there looking for the "right" hinge in the catalog. The crutch is shameful right up until the moment it gets you there. One second later it's no longer a crutch — it's the solution that worked. The Architect never waits for that second. Tool: the crutch vs. architecture matrix You need not a slogan but a blade for cutting your own decisions. Before writing the next line of "proper" infrastructure, run the feature through this table. If most answers land in the left column — you're building ornament. Question for the feature You're building ornament (stop) You're building structure (continue) How many live users asked for exactly this? Zero; "they'll want it" Named people, real requests Why is this being built now? "In case we scale" It hurts today What does this prove? That we're a serious team A hypothesis about the customer How much does it cost to kill? Painful — "so much invested" Five minutes and no regrets Who will see this? Investors / other engineers The user who actually needs it How fast does it give a market answer? Months Days, preferably hours The "building ornament" column is a self-portrait of the Architect of Future Scale, drawn by his own hand. If you recognized yourself in three or more rows — congratulations, he lives in you too, and he just started explaining why your specific case is an exception. I still recognize myself in those rows regularly. The only difference is that now I catch him by the hand before he eats a week, not after. But while the founder suffers from the Architect in his head, there are people for whom the Architect is profitable. The senior engineer makes himself more expensive on the market when the résumé says Kubernetes rather than "one cron script." The accelerator evaluates teams by stack complexity, because that's easier than checking whether anyone is paying. The venture fund wants to see "defensible infrastructure," because it's easier to justify a valuation behind it than behind a Telegram chatbot. Each of them profits from overengineering looking more serious than a crutch — and each of them goes home in the evening while the founder burns runway proving them right. Who pays? The founder's runway — and more months of delay while real users wait for a product that doesn't exist, because the team was building infrastructure for an audience that also doesn't exist. The honest price: you're renting someone else's land If I finished on "the crutch always wins" — that would be self-help, not a dissection. So the other side, no painkillers. When you build on Telegram, you build on someone else's land. Remember that lean team. In June 2024, as the app approached a billion users (TechCrunch officially logged 950 million in July; Durov himself announced the billion only in March 2025), Durov told Tucker Carlson a number that made security experts twitch: ~30 engineers. A spokesperson later clarified that 30 refers only to application and infrastructure developers; the full core team is closer to 60. Even at 60 — that's one engineer per tens of millions of people, no HR department, Durov as his own sole product manager. For me as a founder, this is proof: scale doesn't require a bloated organization, it requires the refusal of one. But the same number that inspires me made security experts call it a red flag. And here it stops being funny — a good carpenter knows that one load-bearing beam across the whole roof looks elegant right up to the first heavy snowfall. A team holding a billion people under a roof on one beam is so thin that a single political decision in Dubai — and your "crutch" loses its foundation along with you. It isn't the man in the knitted sweater who decides your fate — it's whether his single beam can hold a winter he never measured. The crutch buys speed and pays with sovereignty. You're renting auth, billing, and delivery — and the landlord can raise the rent any time, change the terms, or demolish the building. Borrowed capital is borrowed precisely because it gets paid back. The Architect of Future Scale, incidentally, loves this critique — it gives him moral permission to start drawing his own infrastructure "so we're not dependent." And he'll design it again for his mom and two friends, one of whom already unsubscribed — only now on his own servers, head held high, zero users. The honest answer is not "never build your own." The honest answer is: first, the crutch measures whether the land is even worth building a foundation on someday. 97% of "architectural beauty" at the start is premature optimization by Knuth's definition: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." Fighting for sovereignty makes sense in that 3%, when the product has already proved it's alive. Not earlier. Earlier is ornament about independence when there's nothing worth defending. The crutch buys speed and pays with sovereignty. The honest answer is not "build your own" and not "build on someone else's" — it's: first measure whether this land is worth a foundation at all. The signal to drop the crutch: the metric of that 3% "Fight for sovereignty in the critical 3%" — sounds noble and means nothing until there's a counter. Because the Architect of Future Scale loves abstract 3% at least as much as you do: for him every Tuesday is critical, every feature is foundational. He doesn't need a framework — he needs any excuse to finally pour the concrete. So a framework without a trigger is just a permission slip he'll sign himself. Here is the honest trigger, no poetry. The time to replace a crutch with a foundation is when three independent paying customers in a single week hit the same limitation. Not one (one is one person's taste). Not free users (a free user complains for free and leaves for free). Not "I feel like we'll hit a wall soon" — that's the Architect's voice, not the market's. The exact combination: three are paying, three in one week, one wall. That is no longer a premonition of scale — that is a groove worn by real people in the same spot. The carpenter tightens the leg not when he imagines the stool might wobble someday, but when it squeaked in the same corner under three different guests. Earlier than that is not "laying the foundation" — it's planing out of boredom. And notice what is not here. Not "when an investor hinted at defensible tech." Not "when an engineer on Slack said he was embarrassed by the cron script." Not "when a competitor put out a press release about microservices." The signal comes from only one side of the table — the side where the invoice sits and the person who paid it is sitting. All other voices want you to keep planing. A paying customer who hit the same wall three times is the only one who has the right to say "time." Final cut Let's go back to the weavers at the Raytheon factory, threading wire through rings by hand. Their computer was a crutch by any modern measure — 4 kilobytes, a program stitched in with a needle. But that crutch did exactly what it was supposed to: carried people to the Moon and brought them back. Not a byte more than was needed to not crash. And now the mirror I hold up first to myself. While you read this, the Architect of Future Scale inside you has already found in my matrix "a simplification for beginners" and thought: "well, my case is different, I really do need to scale." You might be among that 3%. But count honestly: how many independent paying customers hit the same wall this week? If the answer is "zero, but I have a feeling" — congratulations, that is not the market speaking, that is the Architect speaking in your voice. And your user count right now is exactly what he has friends on the whiteboard — minus one, who just unsubscribed. The crutch shames you because it's naked — you can see the joints, the screws, wire through a ferrite ring. But a naked stool someone sits on is more honest than a framed oak blueprint that no one has yet put a board under. The Raytheon weavers stitched in with a needle exactly enough to carry three people to the Moon and back — not a byte more. The question at the end is one, and it isn't rhetorical. What you're planing right now — is it an instrument to measure reality? Or a mirror to avoid looking at it? Because reality will send the bill regardless. 70% — "ran out of money," in italics on a brass plaque. And nowhere in that line does it note what actually ran out first: not the money, but the willingness to measure even once, before seven years of planing for a client you never once called over to measure. Sources: Lean Startup / Eric Ries — MVP definition: leanstartup.co/resources/articles/what-is-an-mvp Dropbox — HN post "My YC app: Dropbox" by Drew Houston, April 4, 2007 (modest initial attention): news.ycombinator.com/item?id=8863. Waitlist jump 5,000 → 75,000 — via demo video on Digg after TechCrunch50 (autumn 2008), not the 2007 post: Timeline of Dropbox Standish Group CHAOS / Jim Johnson, XP 2002 — 45% never used, 19% rarely (64%), 7% always (four-application sample; original presentation unpublished, numbers corroborated in secondary sources, illustrative): mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used CB Insights — Why Startups Fail (updated 2026 report: 431 VC-backed companies that died from 2023; 70% money, 43% PMF): cbinsights.com/research/report/startup-failure-reasons-top Telegram Bot API — free, 30 msg/sec, Paid Broadcasts up to 1,000/sec at 0.1 Stars: core.telegram.org/bots/faq and core.telegram.org/bots/api Telegram ~30 engineers (Durov statement, Tucker Carlson interview); security experts on red flag; at time of statement — "nearly a billion" users (TechCrunch, June 24, 2024). Spokesperson clarified: 30 = only app/infrastructure developers, full core ~60: techcrunch.com/2024/06/24/experts-say-telegrams-30-engineers-team-is-a-security-red-flag Telegram 950 million users (TechCrunch, July 23, 2024): techcrunch.com/2024/07/23/telegrams-userbase-climbs-to-950m. 1 billion — Durov statement, March 2025: techcrunch.com/2025/03/19/telegram-founder-pavel-durov-says-app-now-has-1b-users Formula Bot / David Bressler — Bubble.io, parental leave 2023, MVP over a weekend, $30K in 3 months, ~1M users; early revenue $3–4K MRR (not $5K): Indie Hackers ($3K MRR) and bubble.io/blog/formula-bot (1M users) SaaS MVP cost guide (2,000–4,000 hours; $25K–$300K+; 2–12+ months): ptolemay.com/post/saas-development-costs Donald Knuth — premature optimization (97%/3%), ACM Computing Surveys 6:4 (1974): ubiquity.acm.org/article.cfm?id=1513451 and en.wikiquote.org/wiki/DonaldKnuth Apollo Guidance Computer — 2,048 words RAM, 36,864 ROM, crystal 2.048 MHz / operating clock 1.024 MHz, core rope: en.wikipedia.org/wiki/ApolloGuidanceComputer. Apollo 11 — launch July 16, 1969, distance to Moon ~376,400 km: en.wikipedia.org/wiki/Apollo11 Personal metrics PanicRadar / NewsHarvest / investigation bot — from the author's own archive, not externally verifiable.