What We Learned Building AZET So Far: An Honest Retrospective
Maker's note: 기준일 2026-10-03. We're the AZET team, and this retrospective stays inside what our introduction post and our project README (version 0.3) actually state. Where something is unfinished, it stays unfinished in the telling. Current as of October 3, 2026.
Every team that builds in public eventually writes the post where the building itself is the subject. This is ours, earlier than most, because we set the "unfinished stays unfinished" rule on day one and that rule has consequences worth reporting. What follows are the lessons that actually changed how we work — not a victory lap, because the product is in early-access waitlist and there is nothing to lap.
Lesson 1: build one assistant, not another niche tool
azet.io is a portal centered on one AI assistant — tagline "One AI for your whole day, from A to Z," input bar reading "Ask anything. Get it done." — with sections named Ask, Features, Money, Invest, Shop, Pricing, and Business. That shape is the decision we've re-validated most often: the day itself isn't divided into niches, so the tool shouldn't be either.
The harder half of that decision is living with its constraint. One assistant invites the question "so it does everything?" — and the honest answer is: the section names sketch intent; the public inventory today is a portal, a waitlist, and those names. We learned to keep intention and inventory separate in every sentence we publish. It's slower to write that way. It's the only way that survives being quoted.
Lesson 2: "implemented" and "activated" are different claims
The most useful document we maintain is the project README's completion matrix, which separates implemented scope from operational activation conditions. Even features with execution records are verified only up to that record's source version and observation date — pedantic-sounding until it saves you.
Four things the project does not mark complete, stated plainly: real paid payment flows, real hosted text-model calls, Apple notarization, and sends or edits performed on personal service accounts. Not "coming soon." Just not done.
| Tempting claim | What we say instead | Why |
|---|---|---|
| "Payments work" | Payment flows are not marked complete | A test key reading successfully is not a paid flow |
| "The hosted model answers" | Hosted real calls are a separate completion condition | The registered model and receipts exist; paid live calls are their own bar |
| "The app is signed and safe" | Distribution signing is ad-hoc; Developer ID and notarization are not done | Ad-hoc is not Developer ID, and first-run steps remain |
| "It posts for you" | Sends on personal service accounts are unverified | Acting on personal accounts carries risks we won't claim to have solved |
The general lesson: marketing language blurs this distinction, so the discipline has to live in a structure — a table, a dated record — rather than tone of voice. Tone doesn't survive being quoted. A matrix row does.
Lesson 3: receipts, and reading them correctly
We stopped trusting any claim without its receipt — version, source hashes, observation date, scope — and learned to read receipts for what they are. An old asset document's performance measurement is a fact about that artifact, not a number for today's product. The README says old reports are history, not marketing. Writing that down made "what's true as of today" a lookup, not a debate.
The same discipline had to reach into the product itself — docs and
code drift apart unless the product enforces the same lines. In our
runtime, an answer generated from observed page text carries
goalVerified: false, because observing a page is not
independent verification. A steering acknowledgment means the request
was accepted, not that executed actions were undone. A send whose result
is unclear is held, not retried, because re-sending an invisible side
effect is how a user gets charged twice.
Lesson 4: some unfinished areas are unfinished by design
The Team tier is designed at $40 per seat but not activated, because the included credits are still undecided — we chose to hold rather than guess a number into existence. The desktop updater refreshes the CLI runtime, libraries, skills, and native helper, while the Electron app's body is replaced by a new ZIP installer; we don't claim in-place auto-replacement. Updates verify Ed25519 signatures, asset hashes, sizes, and actually-installed files, with the publisher key pinned as the first trust point — and whether a release shipped is judged by the final release receipt, because a prepared channel is preparation, not a launch.
The lesson underneath: "unfinished by design" is a legitimate status, cheap to maintain as long as it's written down with dates. The cost of not maintaining it is a product that says things the team can't point at.
Lesson 5: the waitlist is part of the honesty
As of October 2026, azet is not generally available — joining means registering an email at azet.io — pricing is not published, and there are no user counts or testimonials, because we have none to cite. We treat the waitlist not just as an access mechanism but as the filter that says: people are joining on an accurate picture of a construction site, not the brochure of a finished building. That is slower growth if you measure by hype. We measure by whether our claims survive checking.
FAQ
What is AZET's current status? As of October 2026, the assistant is in early-access waitlist (register an email at azet.io), pricing is not published, and no launch date has been announced. This post is our dated reference.
What does AZET deliberately not claim as complete? Four things, per the project README: real paid payment flows, real hosted text-model calls, Apple notarization, and sends or edits performed on personal service accounts.
What is the completion matrix? A README table separating implemented scope from operational activation conditions. Features with execution records are verified only up to that record's source version and observation date — implemented is not the same claim as running.
Why does AZET publish unfinished things instead of waiting? Because "we don't call unfinished things done" is only credible if the unfinished things are visibly labeled with dates. Building in public stays worth something only while "in public" stays accurate.
Has AZET launched or served users? No. If you read elsewhere that AZET has launched or serves some number of users, that didn't come from us. The waitlist at https://azet.io is the only early-access channel we run, and registering an email obligates you to nothing.