( By Munawar Khel / Independent Practice / Freelance UI/UX Designer / 2026 / 9 min read )
Stack
Took Stack from zero to a complete MVP design as the sole designer, covering 12 or more interconnected modules and 33 or more detailed sections
The result and the decision behind it
( What it did )
Took Stack from zero to a complete MVP design as the sole designer, covering 12 or more interconnected modules and 33 or more detailed sections
( The decision behind it )
Adopt Align UI instead of building a design system from scratch
One designer had to cover 12 or more modules on a startup timeline. Building the system first would have consumed the schedule in foundational component work while the actual product questions, how course building relates to recording, what a project contains, where the assistant lives, went unanswered. Taking a proven component architecture moved the effort to where the risk was. Consistency became a property of the foundation rather than something I had to police across 33 sections by hand, and the component structure hands over cleanly to engineering instead of arriving as a pile of screens.
Generated schematic, not a screenshot. Real imagery to follow.
( The account )
Context
Stack is an early-stage startup building an all-in-one platform for the creator economy. The target user is an independent educator, coach, course creator, or knowledge entrepreneur: someone who sells what they know, runs the business alone or with a small team, and has no engineering or operations function behind them. The product ambition is to be the single workspace where that person builds, manages, and sells courses, digital products, communities, and live events, with an AI assistant named Sparky embedded throughout.
I joined at zero. There was no product, no design, and no established interface language, only a proposition and a founding team that needed a complete MVP design they could take into development. The company was pre-launch on Version 1.0, running an early-access waitlist that had drawn over 8,000 creators, which set the stakes: the design had to be credible enough to justify the interest the waitlist had already generated.
The scope was unusually wide for a first product. Rather than a focused MVP around one workflow, the founding bet was that consolidation is the value proposition, so a thin version of the whole surface is worth more than a deep version of one part. That meant designing 12 or more core modules end to end, from onboarding and dashboard through course building, recording, document and presentation authoring, marketplace and monetisation, team management, and account security.
The problem
The creator economy has grown fast, but the tooling underneath it has not consolidated. A creator running a knowledge business assembles a stack of five to ten separate subscriptions and holds it together by hand. Course hosting sits in Teachable or Thinkific, recording in Loom or OBS, documents in Google Docs or Notion, presentations in Canva, community in Circle or Discord, live events in Zoom, storefront in Gumroad, payments in Stripe. Nothing connects, so the creator becomes the integration layer, moving content between tools by copy and paste, CSV export, and Zapier.
That fragmentation compounds into four costs the design had to attack directly:
Two further problems shaped structure rather than features. Because assets are produced in tools with different templates and typefaces, brand consistency across certificates, landing pages, and community spaces is effectively impossible to hold. And as a creator grows into a small team, roles and permissions have to be configured independently in every one of those tools, with calendars and communication living in yet more.
The design constraint on top of all this was that one person had to cover the entire surface. With a solo designer and a startup timeline, no module could afford a bespoke interaction language, because the cost of inconsistency across 12 modules would land on the engineering team as 12 separate builds.
- Lost momentum. A single workflow, drafting a lesson, recording it, publishing it, promoting it, crosses four products. Every crossing costs re-authentication, an unfamiliar interface, and a rebuilt mental context.
- No business view. Student progress, course analytics, revenue, and engagement live in separate dashboards, so no creator can see the business whole. Answering a basic question requires logging into several platforms and reconciling exports by hand, which quietly discourages using data at all.
- Cost before revenue. A working stack runs 200 to 500 dollars a month before a single sale, a barrier that keeps new creators out of the market entirely.
- The blank page. Building a course from scratch, structuring modules, writing lessons, scripting video, designing certificates, is entirely manual and takes weeks. No tool in the stack helps start.
What I did
The organising principle was that consolidation only creates value if the modules actually share something. Placing 12 tools behind one login is a bundle, not a platform. So the design is held together by three shared layers that every module draws on, and it is those layers, not the module count, that make the argument.
A project-based spine. All content, courses, recordings, documents, and e-books, lives under projects rather than in per-module libraries. A creator working on a launch finds everything belonging to it in one place, with the same tagging, search, filtering, and sorting regardless of what type each item is. Project-level actions, share, duplicate, rename, move, delete, behave identically across content types, so learning one content model teaches all of them.
Sparky as a layer, not a destination. The AI assistant is reachable from inside every module and generates in the format of the module it is called from: course structures in the builder, teleprompter scripts in the recording suite, body copy in the document editor, slides in the presentation builder. The assistant follows the work instead of the work travelling to the assistant.
A shared brand kit. Logos, colours, fonts, and templates are defined once and applied automatically across documents, presentations, certificates, and storefront pages, which turns brand consistency from a discipline the creator has to maintain into a property of the system.
On top of those layers sit the modules themselves: a guided onboarding flow that captures goals and tailors the dashboard from the first session, a home dashboard that opens directly into creation, an AI course builder that generates a full module and lesson framework from a single prompt and supports video, text, assignments, and a certificate designer, an in-browser recording suite with screen and camera capture, an AI teleprompter, scene management, and export up to 4K, a document and presentation creator with AI generation and granular sharing, a dual-sided marketplace serving creators as sellers and students as buyers with flexible pricing models, a business suite covering team roles, shared calendar, messaging, and Stripe, PayPal, and Google Meet integrations, and a security and settings area handling two-factor authentication and a 30 day grace period on account deletion.
Adopting Align UI as the foundation rather than building a design system from scratch is what made that breadth achievable. It supplied a component architecture from day one, so the work went into product thinking and module structure instead of into redrawing inputs and menus 12 times.
Outcomes
- Delivered interactive prototypes spanning the full journey from sign-up through course creation to monetisation, with 26 or more prototype connections on the onboarding flow alone
- Produced the product vision behind an early-access launch that drew more than 8,000 creators to the waitlist
- Established three shared layers, a project-based content spine, a context-aware assistant reachable from every module, and a platform-wide brand kit, that make the modules function as one product rather than a bundle
- Adopted and customised Align UI into a coherent product language, holding visual and interaction consistency across the entire surface while sustaining startup design velocity
- Handed the founding team a design ready blueprint with a component architecture that carries into build, rather than screens requiring interpretation
What I learned
Breadth is only survivable if you decide what is shared before you design anything. My instinct at the start was to work module by module, and with 12 modules and one designer that would have produced 12 loosely related products sharing a login, which is the bundle rather than the platform. Settling the project spine, the assistant's position, and the brand kit first turned each module into a small problem instead of a whole one, and it is the reason the surface holds together. I now treat the shared layer as the first deliverable on any multi-module product, before a single screen.
Designing a consolidation product taught me that the competitor is the seam, not the feature. Stack will not beat Loom at recording or Canva at presentations, and trying to would have been the wrong target. What it can do is remove the copy and paste between them, which meant the design effort belonged in the connective tissue: one content model, one assistant, one brand kit. Being explicit about that early stopped me chasing feature parity in 12 directions at once.
Adopting an existing design system was the highest leverage decision on the project and the one I was most reluctant about. The instinct with a new product is to build its language from scratch, and I had to weigh that against the schedule honestly. Taking Align UI meant the interface was not fully original, but it bought back the time that went into the product thinking the founding team actually needed, and it made consistency structural instead of a thing I had to enforce by hand across 33 sections.
The full record / 4 decisions
- My role
- Freelance UI/UX Designer
- Timeline
- 2026
- Platform
- Web application (SaaS), desktop-first responsive at 1440px and 1512px
- Category
- EdTech / Creator Economy SaaS / AI Product
- Status
- New design, delivered
Tools Figma, FigJam, Align UI (design system)
Team Solo designer, working directly with the founding stakeholders
Decisions
Adopt Align UI instead of building a design system from scratch
- What
- Took a pre-built design system as the foundation and customised it into Stack's interface language, rather than authoring components from first principles.
- Why
- One designer had to cover 12 or more modules on a startup timeline. Building the system first would have consumed the schedule in foundational component work while the actual product questions, how course building relates to recording, what a project contains, where the assistant lives, went unanswered. Taking a proven component architecture moved the effort to where the risk was. Consistency became a property of the foundation rather than something I had to police across 33 sections by hand, and the component structure hands over cleanly to engineering instead of arriving as a pile of screens.
Organise all content under projects rather than per-module libraries
- What
- Made the project the primary container. Courses, recordings, documents, and e-books all live inside projects and share one tagging, search, filter, and sort model, with identical project level actions across content types.
- Why
- Per-module libraries would have rebuilt the exact fragmentation the product exists to remove, just inside one login. A creator working on a launch thinks about the launch, not about which tool produced each asset, so the container had to match that. It also compounds: one content model learned once applies to every content type, which lowers the cost of the platform's breadth instead of multiplying it.
Embed the assistant in every module instead of building an AI destination
- What
- Made Sparky reachable from inside every module and context aware, generating course structures in the builder, teleprompter scripts in the recording suite, copy in the document editor, and slides in the presentation builder.
- Why
- A separate destination reintroduces context switching, which is the specific problem the platform is meant to solve, and it makes the user carry the output back to the work by hand. Assistance is most valuable at the blank page, so it has to be present at the blank page. Making the assistant follow the work rather than the reverse is also what makes it read as part of the product rather than a feature bolted to the side.
Design the marketplace and payments in the MVP rather than deferring them
- What
- Included the dual-sided marketplace, flexible pricing models, and Stripe and PayPal integration in the first version design.
- Why
- The promise is that a creator can run the whole business in one place, and a platform that builds courses but cannot sell them sends the user straight back out to Gumroad, which breaks the argument at the exact moment it matters most. Designing the journey through to a completed sale also forced the earlier modules to be honest, because every gap between creating something and getting paid for it surfaces when you follow that line all the way.
( Tags )
- Product Design
- Information Architecture
- Interaction Design
- Design Systems
- Prototyping
- Web
- Payments
- EdTech
- AI Product Design
- End-to-End Design