Stairno 0. The Whole Roadmap

The first post in a development log of Stairno, a brand I build on my own. It is written so that non-developers can follow from the start. When a term is new, its link takes you to that entry in a glossary post.

1. What is Stairno

Stairno is a brand that gathers the things I make under one name. I take freelance work for other people, make games, and build and sell small programs and web services. Run separately, those three would mean three names, three sites and three accounts. So I tied them together.

The name comes from stairno, "star" in Gothic (an old Germanic language). Read in English, it contains stair. I chose it for the image of a star climbing one step at a time from the ground.

2. Why four sites

Solid lines are live today, dashed lines are planned (the labels in the diagram are in Korean)

They do completely different things, so they are separate sites. Someone looking to hire a freelancer and someone looking for a game have no reason to wander the same page. The hub is the front gate in between that only shows "this is what Stairno does". All four domains were bought on 17 October 2026.

3. Why one account

Four sites easily turn into four sign-ins and four payment systems: a sign-up form on every site, a payment provider on every site, a refund process on every site. For someone running everything alone, that means doing the same work four times, with four times the bugs and security holes.

So I decided to build it like an Amazon account.

• One Stairno account signs you into every Stairno site and product except the hub
• Register a card once
• See purchases, subscriptions and downloads in one account center (account.stairno.com)
• Payments, subscriptions and entitlements are handled in one shared API (api.stairno.com)

The other sites do not build sign-in or payments themselves. They just call these two. That is why every arrow in the diagram above gathers in the middle band. The hub has no account screens and no payments, only an account menu in the header.

4. Roadmap

I set the order on 18 October 2026. There are no dates, only order.

Why this order

• The design package comes first. So that every site, starting with the account center, begins with the same look as the hub. Building sites first and matching the look later means fixing every site
• The account center and API come before the sites. Every other site calls these two. They are the only servers, and the sites start as introduction pages and add sign-in and payments later only where needed
• Real payments are step 9. Taking real money requires business registration and a provider contract first. Until then every payment is in test mode, and the design makes switching a matter of swapping keys
• Works comes after Labs. A freelance site becomes useful once a few reviews have piled up. Until then, freelance work comes through freelance platforms

5. Where things stand

Step 4 is done. All 10 production payment rehearsal scenarios passed. The rehearsal scripts and connection details are gone, the shared documents match the Markdown originals again, and the pending changes shipped as v0.4.3. The closing day is in section 12 of part 4a. Step 5, Labs, is next, but first come the jobs the rehearsal turned up: refund requests in the account center, "keep me signed in", and three bugs found along the way.

The pace may look oddly fast. The plan said 1–2 weeks for sign-in and 2–3 weeks for payments, but the code went in within a day. Most of the code was written by an AI coding agent (Claude Code). I set the scope and made the decisions, checked the results, and did what a person has to do, such as dashboard settings and entering cards. That speed also meant missing things, and each post says so openly.

6. Working principles

Four principles run through the whole series. They come back in each post.

1. Can one person run it? Technology is chosen not for "does it look impressive" but for "is it less work to run alone". One language (TypeScript), servers someone else manages, fixed costs close to zero
2. Documents first. Before code, write the project plan, requirements and design specifications. If documents and code disagree, fix one of them in the same change
3. Tests first. TDD. Write a failing test first, then make it pass
4. Check in production. Do not stop at passing tests. At the end of each stage, go through the acceptance checklist item by item on the real service address

7. Series contents

There are five glossary posts.

8. Tools in this series

No need to be put off by the names. They are all "parts someone else made".

9. Repos

Next: Stairno 1. The shared design package