Something rare is loading.

0% · summoning #001

Back to the collection

#006 · Systems Architect · Rare · AKASHA tenure, 2021 to 2026

World Builder

A guided tool that turns a developer-only world configuration into something a community manager can create, review and publish, without hiding the decisions that matter.

Lead Product Designer · AKASHA FoundationThe whole product surface: information architecture, the step-by-step forms, validation, the Build Preview and the Dashboard, iterated with engineering every sprint against the real data model.

EvidenceA world configured, previewed and saved to decentralized storage with no code. Shipped in AKASHA Core, where the source is public.

An illustrative run of AKASHA World Builder, not connected to any deployment service. On the left, the shipped World Builder flow: a world named Cat World gets an icon and an instance URL, the World Configurator keeps the default three-column layout, four extensions are added (Authentication, Antenna, Vibes and Featured Topics) and Antenna becomes the homepage. On the right, a preview of the World responds to each change: its name and icon, a sidebar that follows the order the extensions were added, the Featured Topics widget and the Antenna feed. The scene ends on the Dashboard's World Preview, the step that shows the result before deployment.

The challenge

A world was a hand-edited configuration file plus a registry file, so only a developer could create or change one, and a mistake only showed when the world failed to load.

What I led

Turning that file into four short forms grouped by decision, preventing the common mistakes before they happen, and a Build Preview before anything is shared.

What shipped

Create, Configure, Customize, a Dashboard that reads the configuration back, and a Preview that opens the world with it. In the AKASHA World extensions registry today.

01 · The problem

One transformation.

A developer-only configuration file became a guided product a community manager can finish in minutes.

An AKASHA World is an instance of AKASHA Core: a shell, a homepage app, an extensions app and a set of installable extensions. All of it is described by one configuration object. Before World Builder, that object only existed as code.

The original problem
The configuration lived in a TypeScript file inside the world's codebase, next to a registry file that pointed every extension to its bundle URL. Creating or changing a world meant a developer editing both, rebuilding and redeploying. A wrong package name or a missing registry entry only showed up when the world failed to load.
Who it was for
Community managers and world owners: people who run a community and want their own World, and who cannot or should not touch the codebase. Developers were the second audience: the saved configuration is what they bootstrap a hosted world from.
The constraints
Every value maps to a decentralized data model on Ceramic, so a choice is a reference to a real extension, not a label. A world's name is its key and cannot change. The tool had to ship as an installable app inside AKASHA World, not as a core feature. One world per account at a time.
The intended outcome
A non-developer creates, configures, customizes and previews a world configuration with no code, understanding each choice. The result is saved to decentralized storage, where a developer can pick it up to run the world.
02 · Before and after

The same decisions, moved from a file to a form.

This is the shipped configuration of AKASHA World itself, from the open-source repository. Every key on the left became a field on the right. Nothing was dropped; the technical choice is still the user's, it is just asked in plain language.

Beforeworlds/akasha.world/src/akasha-world.conf.ts
export const akashaWorldConfig: WorldConfig = {
  title: 'AKASHA World',
  worldIcon: { basePath: '/icons/world/', ... },
  layout: '@akashaorg/ui-widget-layout',
  homepageApp: '@akashaorg/app-antenna',
  extensionsApp: '@akashaorg/app-extensions',
  defaultApps: [
    '@akashaorg/app-vibes',
    '@akashaorg/app-auth-ewa',
    '@akashaorg/app-profile',
    // '@akashaorg/app-world-builder',
  ],
  socialLinks: [{ icon: 'Github', link: '...' }, ...],
};

registry-overrides.ts: one entry per extension, with the URL its bundle is served from. Also edited by hand.

Afterthe same keys, as the form asks them
  1. titleWorld nameCreate Your WorldRequired, at least 2 characters, locked once the world exists. The form says so before you type.
  2. worldIconWorld iconCreate Your WorldAn upload instead of a folder convention. The hint carries the real requirement: transparent, at least 96 by 96.
  3. extension sources (registry-overrides.ts)Extension publisherCreate Your WorldWhose published extensions the world trusts. Defaults to AKASHA's own publisher; still a visible choice.
  4. layoutLayoutWorld ConfiguratorStill an explicit choice of a layout extension. The help text explains what a layout is: how content is seen in a page, three columns by default.
  5. extensionsAppExtension AppWorld ConfiguratorWhere the world's extensions get published and installed from.
  6. defaultAppsWorld ExtensionsChoose Your extensionsAdd from a searchable list of published extensions. The order you add them is the sidebar order, and the form tells you.
  7. homepageAppHomepageChoose Your extensionsOnly offers the extensions you added, so the world can never open on an app it does not have.
  8. description, keywords, guidelines, socialLinksCustomise your WorldDashboard, optionalMeta information lives in its own model, so it is its own optional step and never blocks a world from being configured.
What had to stay technically true

A field is still a reference to a real extension on the network, so the options come from the registry, not from a list typed into the design. The name is immutable because it is the record's key. Saving writes to Ceramic, a public decentralized network, which is why the tool shows a preview before it asks you to commit, and why the Dashboard shows the World ID and links to the developer documentation instead of pretending the hosting step does not exist.

03 · The flow

Five steps, two of them optional.

The flow is the recording, step by step. Each step saves its own record, so a world owner can stop after any of them and come back; the Dashboard shows what is done and what is still empty.

  1. 01Open

    Install World Builder from Extensions, connect, read what it does and accept the terms.

    Required
  2. 02Create

    World name, icon, instance URL and extension publisher.

    RequiredSaves AkashaWorld
  3. 03Configure

    Layout and extension app, then the extensions and the homepage.

    RequiredSaves AkashaWorldConfig
  4. 04Customize

    Description, keywords, guidelines URL and social links.

    OptionalSaves AkashaWorldMetaInfo
  5. 05Preview

    The world opens in a new tab with the saved configuration loaded.

    Before you share it
Gates, as shipped
  • Create stays disabled until the name is valid and the URL, if given, is a URL.
  • Next stays disabled until a layout and an extension app are chosen.
  • Homepage stays disabled until at least one extension is added.
  • Save Config stays disabled until the homepage is chosen.
RecordingWorld Builder, configuration UI. The full run, 46 seconds, from Welcome to Configuration Saved.
12
01 Open. The welcome card, with the three-step progress dots.
  1. 1One sentence on what a world is and what you can do with it.
  2. 2Get Started, then one terms screen; no tutorial.
123
02 Create Your World, mid-typing.
  1. 1The lock is explained before you type: the name cannot be changed once set.
  2. 2Instance URL is validated as a URL but can stay empty.
  3. 3Extension publisher defaults to AKASHA's registry: visible, not hidden. Create stays disabled until the form is valid.
123
03 World Configurator, step one.
  1. 1What a layout is, in one line, next to the choice.
  2. 2The extension app: where this world's extensions come from.
  3. 3Next only once both are chosen.
1234
03 Choose Your extensions, step two. The order you add them is the sidebar order, and the form says so.
  1. 1Added is a state on the card, not a separate list to manage.
  2. 2You have selected: the running summary of the configuration.
  3. 3Homepage only offers the extensions you added.
  4. 4Save Config only once a homepage is chosen.
12
03 Configuration Saved.
  1. 1The success state repeats the decision: the layout and the four extensions.
  2. 2Back to Dashboard, where the preview lives.
123
05 The Dashboard, with World Preview at the top.
  1. 1World ID with copy, and a link to the developer documentation for the hosting step.
  2. 2Preview opens the world in a new tab.
  3. 3Each section reads back what was saved, with an edit action.
04 · Decisions

Five decisions, and what each one did for the user.

The brief was to simplify without hiding. Each decision below removed a way to get it wrong while keeping the real choice in the user's hands.

  1. 01

    Information architecture: group by what the user is deciding, not by the data model

    Why

    The data lives in three Ceramic models (world, config, meta info) and a user does not think in models. Grouping by decision, who you are, how the world is built, how it presents itself, let each group be one screen with one job.

    How it helped

    A community manager can read a step and know what it affects. Developers still find every model field, because the Dashboard reads them back under the same headings.

    Three models in the public schema; four forms in the app.
  2. 02

    Step-by-step configuration, each step saved on its own

    Why

    Creating a world and configuring it are different commitments. Create is the irreversible one (the name), so it is a short form by itself; Configure has two screens and can be redone.

    How it helped

    You can stop after any step and come back. Every success screen offers Do it later next to the next step, and the Dashboard shows empty states for whatever is still missing.

    Create Success and Config Success screens, Dashboard empty states.
  3. 03

    Prevent errors instead of reporting them

    Why

    A hand-edited file fails at load time. The form can fail earlier, or not at all.

    How it helped

    Buttons stay disabled until the step is valid. The homepage list only contains extensions you added. Rules are stated up front (the name lock, the icon size, the URL format) and validated inline. The only toasts are for things that genuinely can fail: an upload or a save to the network.

    Form schemas and disabled states in the public source.
  4. 04

    A Build Preview before anyone commits

    Why

    The configuration is only real when a world loads with it. Reading a summary is not the same as seeing the sidebar, the homepage and the widgets it produces.

    How it helped

    Preview opens the world in a new tab with the saved configuration applied. It is the does-this-look-right moment, and it sits at the top of the Dashboard, above the edit actions.

    Dashboard, World Preview; preview route in the public source.
  5. 05

    Honest deployment and feedback states

    Why

    Saving writes to a public decentralized network, and hosting a world is still a developer step. Pretending otherwise would have been the kind of hiding the brief ruled out.

    How it helped

    Success screens name what was saved. The Dashboard shows the World ID, says you can set up your own world from this configuration, and links to the developer documentation. The not-connected state says you must be connected before anything is created, and offers Connect.

    Dashboard copy and the not-connected state in the public source.
05 · Build Preview

The Build Preview is the product's promise.

Preview World, from the Figma file: Cat World as a member would see it, the Antenna homepage, the sidebar in configuration order, empty widgets explaining what will show here.
Design, FigmaPreview World, from the Figma file: Cat World as a member would see it, the Antenna homepage, the sidebar in configuration order, empty widgets explaining what will show here.

A world configuration is a set of references. The preview is the only place where those references turn back into a product: the sidebar lists the extensions in the order they were added, the homepage opens, the widgets render with the world's name and icon. Showing that before the configuration is shared is what let the tool stay honest about the system and still feel safe.

What it checks
That the layout, the homepage and the extension order produce the world you meant.
When it appears
After Configure, and again at the top of the Dashboard, before the edit actions.
What it is not
Not a deployment. The world is previewed from the saved configuration; running it on a domain is the developer step the Dashboard links to.
Shipped: the Dashboard's World Preview section, from the recording. Preview opens the world in a new tab.
ShippedShipped: the Dashboard's World Preview section, from the recording. Preview opens the world in a new tab.
06 · What shipped

What shipped, and where it stops.

Each line carries its status: shipped in the app, designed into the flow, intended for the people it serves, or outside the tool's scope.

StatusClaimWhat that means
ShippedA world configured and previewed with no codeCreate, Configure, Customize, Dashboard and Preview are in the shipped app. The source is public in AKASHA Core.
ShippedConfiguration changes without a developer editing the codebaseWhat previously needed an edit to the config and registry files and a redeploy is a form a world owner fills in.
DesignedError prevention over error reportingDisabled states, inline rules and dependent options were designed to remove the common configuration mistakes before they happen.
IntendedCommunity managers and world owners as first-class usersAny connected account can create one world at a time, so community managers and world owners can set one up themselves.
Out of scopeHosting a worldWorld Builder saves and previews a configuration. Running the world on a domain follows the developer documentation the Dashboard links to.
How it was built

I designed the flow in Figma and iterated with the engineers every sprint against the real data model and hooks, not against a handed-off spec. The recording on this page is the shipped app; the Figma frames are the design; the source is public.

The impact

What changed.

ShippedA world configured and previewed with no code

Create, Configure, Customize, Dashboard and Preview shipped; the source is public in AKASHA Core.

ShippedNo developer in the loop for configuration changes

A form replaced editing the config and registry files and redeploying.

DesignedErrors prevented rather than reported

Disabled states, inline rules and dependent options guide every field.

The design lesson

Technical complexity is not the enemy of a simple product; hidden complexity is. World Builder kept every real decision in the user's hands, asked it in their language, removed the ways to get it wrong, and showed the result before asking anyone to commit. That is the pattern I bring to developer platforms and no-code tools: make the system legible, then make it safe.

All seven cards
Next card · #008 · UncommonEtherlakenConcept, identity, IA, design and handoff. One two-week sprint.#002 · LegendaryAKASHA WorldEight composable apps. One coherent social platform you own.

Got something complex?

Let's make it feel simple.

Let's talk
Let's talk

Let's make
it happen.

For product leadership, ambitious projects, and interesting collaborations.