Build something.
Go deeper.

Before you startFunctions, basic data types, and running a test in your language. Go is a good fit; the exercise does not depend on it.

1. 01 Start here Organization membership Identity, permissions, and explicit errors +

   Build this much

   Seed one organization, a fixed owner, and a few existing users. Write functions to add a member, change a member between viewer and editor, and list members. Only the owner can make changes. Begin with in-memory storage and pass known actors from a test harness.

   Your finish line

   Tests show an owner adding and updating a member, a viewer being denied, and a duplicate membership being rejected. Each rejection leaves the original state intact and returns an error the caller can distinguish.

   Make one thing fail

   Ask an actor from another organization to change a known member ID. Predict the result, run it, and prove that knowing an ID does not grant permission.

   Apply a concept

   Compare two error designs against the same tests. Can a caller recognize forbidden, duplicate, and missing-member outcomes without inspecting message text?

   Scope & optional extensions

   Keep owner transfer, sign-up, and invitation email outside this first slice. If you expose an HTTP API later, derive the actor from an authenticated session; the fixture actor is only a test input.

2. 02 Next step Audited role changes Transactions, failure visibility, and boundaries +

   Build this much

   Extend the membership module with a relational database and an initial migration. Store each successful role change and its audit entry in one transaction: actor, organization, member, previous role, new role, and operation ID.

   Your finish line

   Restart and find both the accepted role and its history. Reject the audit write during a role change: neither write commits. An unauthorized attempt creates no successful-change audit entry.

   Make one thing fail

   Inject a failure between the role update and audit insertion. Trace the operation through structured logs, then inspect the database. The evidence must explain both the failure and the rollback.

   Apply a concept

   Audit answers who changed what. Operational logs explain how execution went. Keep secrets out of both, and preserve useful error causes without exposing database details to API callers.

   Scope & optional extensions

   Add a read-only history query, then propagate context across an HTTP request and a queued job. Document what identifies the request, what groups the workflow, and which operation caused the job. Add a second adapter only when it serves a concrete test or integration.

Before you startBasic HTML and CSS, plus components and local state in one framework. Use the framework and styling tools you want to practice.

1. 01 Start here One design, one complete screen Visual fidelity, responsive layout, and accessibility +

   Build this much

   Choose a design you may reuse, such as a Figma Community settings or members screen, and credit its author. Implement its type, spacing, colors, and a few reusable controls. Use local fixture data and make one form work with local state.

   Your finish line

   Compare the implementation with the reference. Check a narrow screen, a wide screen, and widths between them. Long names fit, controls have labels, keyboard focus is visible, and submitting invalid input gives a useful message.

   Make one thing fail

   Replace the neat sample content with a very long name and an empty list, then complete the form using only the keyboard. Record the layout or interaction that broke and the fix.

   Apply a concept

   Use component composition to share behavior and design decisions. Check whether each component boundary makes the second screen easier to build and change.

   Scope & optional extensions

   Add a second screen that shares the controls, then change a spacing or color token. Explain what should change together and what belongs to one screen. A complete design system can grow from repeated needs.

2. 02 Next step A screen that handles uncertainty Async state, stale responses, and recovery +

   Build this much

   Connect the screen to a controllable mock API. Add member search with loading, results, empty, and failed states. Let the mock delay, reject, or reorder requests. Give a failed read an explicit retry action.

   Your finish line

   Search for A, then B, and return A last. The screen still represents B. An empty response looks different from a failed request; retry succeeds; state changes remain understandable to keyboard and screen reader users.

   Make one thing fail

   Return search results in the wrong order, then fail the current request. Explain which response may update the screen and show a recovery path that keeps the current search input.

   Apply a concept

   Model the states and allowed transitions explicitly. A small API boundary lets the same screen use controlled fixtures and a real service later; the mock does not prove server authorization.

   Scope & optional extensions

   Add a role-edit form with pending, validation-error, and successful states. Preserve input after failure. Decide how a lost response is reconciled before retrying a mutation; a disabled button alone does not prevent duplicate server effects.