Osokoro is four things: a waitlist product, a form builder, an agentic IDE, and an inbound phone agent. They share one account and one bill and almost nothing else that a customer can see.
That arrangement is easy to read as a company that could not decide. It is worth explaining what it actually costs and what it actually buys, including the parts where the answer is "not much".
The four
Osokoro — waitlists and pre-launch validation. A hosted launch page, referrals, custom questions,
and analytics on what people said. Free to $100/mo. Lives at osokoro.com.
DevForm — one question per screen, conditional logic, answers validated in the database before
they are stored. $0 to $49/mo. Lives at devform.osokoro.com.
Codoro — an agentic IDE for macOS that switches models mid-task and holds a spend cap you set. $0 to $200/mo, or $40 a seat. In preview; there is no public download.
Osokoro Phone — an inbound line that answers on the first ring, on a SIP number you already own. 23 cents a minute. Private beta, approved one business at a time.
Two of the four cannot be bought today, and I would rather that appear in the second paragraph than in a footnote.
Separate sites, on purpose
Each product has its own hostname, its own header, its own footer, and its own metadata. A visitor
landing on devform.osokoro.com sees DevForm, not a company with four things in a dropdown.
That is not branding preference. Search treats a subdomain as a mostly separate entity, and a page that tries to rank for "typeform alternative" while also explaining a phone product ranks for neither. It is also honest: somebody who wants a form builder does not care that we also do voice, and putting it in front of them is noise.
The cost is real. Four sites means four headers, four footers, four sets of chrome to keep in step —
and they are deliberately four sibling files rather than one parameterised component, because a
<Header product="devform" /> with six conditionals inside it is harder to be right about than four
short files that each name their product.
What the shared account genuinely buys
One sign-in, one bill, one place the data lives. Nobody needs a second account to try the second product.
Consistency where it matters. Same accessibility standard — axe over every session-free page, WCAG
A and AA, both themes and both viewports. Same three languages. Same security headers. Same honesty
guard: a script scans every .ts, .tsx, .md, .mdx, .sql, .mjs and .json in the repository
against a list of claims we are not allowed to make, and it fails the build. Four products cannot each
independently decide how much to overstate.
Infrastructure that got better because four things needed it. The clearest example is billing. Codoro's usage model — reserve money before a run, settle against real usage — forced a distinction between a hold and a charge that Phone then needed too, for the same reason: both bill for something whose price is not fully known when it starts. Neither would have got that right alone.
What it does not buy
Being straight about this, because "one platform" implies more integration than exists.
The products do not talk to each other. A DevForm response does not become an Osokoro signup. A Phone call does not appear anywhere near a waitlist. There is no shared customer record across them beyond the account itself.
They also do not share a pricing ladder, and conflating them is a mistake made inside this codebase more than once. Osokoro's plans are Free/Starter/Everything/Studio at $0/$10/$20/$100. DevForm's are Free/Starter/Pro/Business at $0/$9/$19/$49. Codoro's are Hobby/Pro/Pro+/Ultra/Teams. Three separate ladders, three separate constants, because a product's price should follow its economics and not its siblings'.
Codoro's economics are the clearest illustration: most of a $20 Codoro subscription is prepaid tokens at a 40% markup, which nets around 25% of revenue after Stripe. Osokoro at $20 is software margin. Same price, different business, and the affiliate programme pays 50% on one and 10% on the other for exactly that reason.
Three languages, everywhere
All four public sites are in English, Spanish and Brazilian Portuguese. es without a region — the
differences between Peninsular and Latin American Spanish matter for marketing voice and barely at all
for product UI. pt-BR with the region, because Brazilian and European Portuguese diverge in
ordinary vocabulary enough that a single pt would read as foreign to one of the two audiences.
The legal documents are deliberately English-only, and say so in the reader's language. A translated
contract is a different contract, its enforceability is a question for a court rather than a git diff, and which version somebody accepted is a legal fact about that person that has to stay one
scalar.
Where things actually are
- Waitlist — core paths are production-fit. Public surfaces green.
- DevForm — ready for a controlled beta.
- Codoro — ready for a controlled team beta; blocked on a signed native build.
- Phone — ready for isolated tenant tests; blocked on registered numbers and recorded real calls.
And the fact that contextualises all four: no organisation has ever paid for anything. Live billing has never processed a real charge. There are no case studies on this site because there are no cases, and any you eventually see will have a date on them.
Email now runs through our production SES account. Everything includes one custom sending domain and Studio allows several, each activated after its DKIM records are verified.
Four products, one account, and a company that is earlier than the number of products suggests. That seemed worth writing down.