How a solo developer runs 18 services — mrlatte.net's setup, as its own service pages describe it

1. Executive summary

First, a disclosure of interest. Eazler, which publishes this article, is a company where, according to the mrlatte.net About page, the operator worked as an executive and developer from August 2015 to December 2016 [2]. We wrote this article from public pages only, without asking the operator anything, and the operator did not review it.

Some terms. Static site generation (SSG) means building the HTML files in advance, at build time, instead of having a server generate each page when a request arrives. Firestore is Google Firebase's document database; a single project can hold several named databases. Firebase Hosting deploys static files, and Firebase App Hosting deploys apps that need server rendering. Credits are the shared in-app points used across this family of services to unlock paid features; we follow the operator's own term for them.

The figures and quotations in this article are as they appear on mrlatte.net's pages (quotations are our translations from Korean). The response headers and HTML traces are what we checked ourselves on 2026-09-19. We did no performance measurements of our own.

2. What it runs: all 18 services

These are the 18 services on mrlatte.net's service list page [1]. We condensed the first paragraph of each description page into one line, and for languages and revenue mechanisms we included only what each page states. The service name links to the live service; the "Page" link goes to its description page on mrlatte.net.

16 of the 18 are marked "running," and the two mobile apps, Pawtelier and ToonBooth, are marked "archived," so for those we link only to the description pages. Weple is a contract-work storefront rather than a product, but the operator counts it among the 18, so we kept it. "Per hreflang" in the languages column means the description page gives no language list, so we checked the live service's hreflang tags.

3. One set of infrastructure: a database per service on the same Firebase

The Weple page states the stack in one line: "the stack proven by building and running 18 services first-hand (Astro/React/Firebase/Expo)" [4]. The "current status and operating signals" section of each service page is more specific.

The six pages point the same way. All six services that disclose their infrastructure use Firebase, and two pages, Libsac and DeepThought, name the project mrlatte. The pages do not say whether the other services sit in the same project, so that part is our inference. What they have in common is that each service gets one named Firestore database and one hosting site. Services for which static pages are enough go on Firebase Hosting; services that need state after login go on App Hosting. Deployment is via GitHub Actions. Launching another service then means not "standing up new infrastructure" but "attaching one more database and hosting site to the same template."

What we checked in the response headers fits the same picture. Of 17 live domains, 12 returned server: envoy and via: 1.1 google. The other 5 returned Fastly-style cache headers (x-served-by: cache-icn…): mrlatte.net, startupxo.com, reputo.net, bunn.kr and theweple.com. StartupXO and Reputo, whose pages say "static pages on Firebase Hosting," are in the second group; Typdit and DeepThought, whose pages say "App Hosting," are in the first. Whether the two header patterns correspond directly to Firebase Hosting and App Hosting is our inference, and nothing we found contradicted what the pages state. In the HTML, 6 sites had Astro island markup, and Forkarium showed traces of Next.js.

4. Static first: an early-morning scheduler instead of a server

The word the service pages use most often is "static." When we saved the text of all 18 pages and counted, it appeared 50 times. Instead of a server doing work on every request, the data is baked into HTML at build time and the site is rebuilt once a day. The Libsac page gives both the reason and the structure.

The same principle appears in other services. StartupXO calls its approach "serverless search": "the browser searches data that was baked into the pages during the build, finding news, ideas and talent all at once" [7]. DeepThought's published maps are indexed by search engines through prerendered static pages and a sitemap, and in the page's words they serve as "a visual table of contents for the family's AI/tech insights and an internal SEO hub" [8]. Reputo lists "real-time recommendations / an algorithmic feed (to keep the strengths of a static site)" under "what I gave up" [9].

Static-first goes together with multilingual pages. Instead of choosing the language on the server, the sites split languages by path, such as /ko /en /ja /zh, and the build checks the language files. Reputo writes, "No page passes the build unless all five language files exist" [9]. The hreflang tags we checked numbered 5 each for GameSnapshots and Bessatsu, 5 for DeepThought (including a duplicated Chinese variant), 5 for DoYouBox and 9 for Weple. Libsac, by contrast, says it "deliberately has no multilingual support or language switcher, because events, contests and performances are domestic information" [5]. Multilingual is the default, but the audience comes before the principle.

5. AI for production and judgment: people review the sentences that reach the screen

The About page says: "I use AI to fit the purpose. Not because it is trendy, but when it raises real user value" [2]. The service pages show that, in practice, AI plays two roles. One is a production pipeline for output at a scale no person could write by hand, such as multilingual reports, with the operator reviewing the results. The other is a judge that produces no sentences for the screen. There is no AI inside the editors that users work in.

Two cases show the direction. StartupXO's retrospective says: "If I did it again: I regret starting the ideas with auto-generation. The volume went up, but there was little reason to read them" [7]. DeepThought writes that "the editor came back to life by solving the blank-canvas problem with publications worth reading, not with AI," and lists removing the AI it had attached to the editor under "if I did it again" [8]. Rather than using more AI everywhere, the person running eighteen services has been removing it from the places users touch directly. What remains is mass production with review behind it, and tasks such as translation, normalization, judgment and validation, where mistakes can be caught mechanically.

Model choices are practical too. Reputo puts "self-hosting an LLM (external APIs win on both cost and quality)" on its gave-up list [9], and Libsac uses a model from the cheapest tier for normalization [5]. This is the same reasoning as the judgment-only model we covered earlier on this blog. Tasks whose answers have a fixed format do not need a large model.

6. A family of services that feed each other: shared accounts, credits, cross-links

The pages call the eighteen "the Mr. Latte family" (8 times, counted the same way). According to the pages, the family shares three things, not just a name.

• A shared account and payment hub. BootSignal's payments are "taken through Polar, and checkout goes through accounts.mrlatte.net" [6]. Typdit's higher tiers are also "processed as subscription products of an external payment provider via the family's shared account hub, and a webhook updates the plan field in each service's user document. Instead of building new payment infrastructure, the existing one was reused" [13]. In other words, a webhook that receives the payment notification changes the plan field in the user's document for that service. BootSignal says it uses "login (a shared Google account), saving and multilingual features without a separate build or backend" [6]. As of 2026-09-19, when we checked, accounts.mrlatte.net returned 200.
• A shared credit economy. DeepThought writes, "The shared credit economy is linked across the whole mrlatte family" [8]. InverseOne, when it added charges for unlocking stocks, wrote that it "reused the payment code from the game flow (no new payment code)" [14]. Credits also appear on the GameSnapshots, Bunnkr, Libsac and ToonBooth pages. In effect, the services that use credits share one wallet, and some services, such as Weple, have nothing to do with credits.
• Cross-links and division of roles. DoYouBox lists among its revenue mechanisms "natural links from the quiz flow to related services (including the family)" [15], and DeepThought tracks "internal referrals to the family's insights (especially startupxo)" as a monitoring metric [8]. The AI prompt market that used to be part of Out of Stealth was split off and moved to BootSignal [10]. When we scanned the live HTML, BootSignal was mentioned on 8 of the 17 domains, and mrlatte on 8.

The revenue model also comes down to one line: reading is free; only tools that stay with your account are paid. StartupXO writes, "If reading were locked, the reason this site exists would disappear" [7], and Reputo puts "a reading paywall (the SEO funnel and affiliate revenue come from the free reports)" on its gave-up list [9]. BootSignal has a single price, and "the subscription check looks only at the expiry date, not the widget name, so no extra fee applies as the catalog grows" [6]. The design removes the work of managing a price list altogether.

7. Recording every reorganization: what worked, if I did it again, what I gave up

All eighteen pages use the same sections: positioning; market and problem definition; core target users; value proposition; revenue; current status and operating signals; retrospective and next hypotheses. In particular, the three slots "what worked / if I did it again / what I gave up" are filled in for every service, and decisions carry dates. Picking out only the reorganizations recorded in 2026 gives this:

The retrospectives record failures too. Typdit's "if I did it again" reads: "When changing the nature of the service, I would have tied the cleanup of old pages and the publishing of new pages into the same sequence. Right after the cutover, the leftover old pages were briefly out of step in search results and internal links" [13]. The operator's blog post of 2026-09-01 shows where this habit comes from. It calls a day "a deploy with no rollback" and says to "record what changed, like a commit message" [3]. The person running eighteen services relies on documents, not on memory. And because those documents are public, this article was possible.

8. What a one-person studio can take away today

• Extract a template from your first service before launching the second. One project, a database and a site per service, the same deployment pipeline. Only if the second can ship "without new infrastructure" will there be a third.
• Serve as static files whatever can be served as static files. Rebuild information that only needs a daily refresh with an early-morning scheduler. No server means no server outages to respond to. If, like Reputo, you put "real-time feed" on your gave-up list, you will not waver when feature requests arrive.
• Put AI only where a review follows it. Give mass production a review step, and limit judgment roles to tasks where mistakes are caught mechanically, such as translation, normalization, classification and checks for missing items. Keep it out of the editors that users work in directly.
• Let the build check completeness. A build that passes only when all five language files exist is more reliable than human memory.
• Build accounts, payments and points once. Route payments through a hub instead of adding a new payment setup to each service. Keep to a single price where possible, with a check that looks only at the expiry date.
• Keep reading open and sell only tools. If a service's search traffic comes from its free pages, a paywall cuts off that traffic.
• For each service, write down "what worked / if I did it again / what I gave up," with dates. That is where you learn how much you can delete when you reorganize. Made public, it also helps in client quotes and hiring conversations.
• To build a family, share the wallet (accounts and credits) before the brand. Cross-links can be added later, but merging credits and accounts later is a migration.

9. What this is not yet

• All the evidence is pages written by the operator. The infrastructure, automation and retrospectives are the operator's own description, not something we confirmed through code or dashboards. The only things we checked independently are response headers, HTML traces, hreflang tags and whether the domains respond.
• There are no performance figures. Traffic, revenue, subscribers and time invested appear on none of the pages. This article only sets out "how it runs," and makes no judgment on "whether it runs well."
• We could not confirm that it really is one person. "Solo" in the title follows the operator's own description. The Libsac and Reputo pages say "one-person operation," but the Weple page also uses the phrase "small team." How much outside collaboration is involved is unknown.
• The hosting inference comes from header patterns. We read the Fastly-style headers as Firebase Hosting and the Google front-end headers as App Hosting, and this did not contradict what the pages say, but headers alone do not settle it.
• Launch dates mix page dates and dates in the body text. Three services have the same page date, 2024-01-01, so we did not use it as a launch date. The "Start" column in the table includes only what the body text states.
• There is a conflict of interest. The operator worked at Eazler, this blog's publisher, in 2015–2016. We did not ask the operator anything, and the operator did not review the article before publication.
• The pages change often. Seven reorganizations are recorded in 2026 alone. The quotations here reflect the wording as of 2026-09-19, and the linked content may change.
• Limits to generalizing. This structure is suited to content, curation and tool services. There is no evidence that the same template fits services that need real-time collaboration or high transaction throughput. The operator also put "real-time collaboration" on DeepThought's gave-up list.

10. Sources

All checked on 2026-09-19. [1]–[15] are mrlatte.net pages in which the operator describes their own services, so they are not neutral sources. We checked the response headers and HTML traces ourselves.

Editorial standard: in every table we kept the operator's self-description apart from what we checked ourselves, and we wrote no sentences about performance. We disclosed the past relationship between the publisher and the operator at the start of the article.