Building a home for creative and technical minds across MENA.
Software Engineering · Product Design · Independent Project
The idea
The Middle East and North Africa have never lacked creativity. What I think we've lacked are enough spaces for that creativity to be explored, shared, and taken seriously.
There are talented developers, writers, designers, researchers, and people experimenting with things that don't necessarily fit into one profession. But creative work in MENA doesn't always have the visibility, support, or opportunities it deserves. That doesn't mean the talent isn't there. Much of it simply remains undiscovered.
That's where Mudolo began.
I wanted to build something inspired by the simplicity of platforms like Substack, but with a broader purpose. A place where developers could share code and ideas, writers could publish their thoughts, designers could present their work, and curious people could discover things outside their own disciplines.
I didn't want Mudolo to be another platform where everyone had to present themselves as an established professional.
A student learning their first programming language should have as much reason to be there as an experienced software engineer. The same goes for an intern publishing their first article, a designer experimenting with a new medium, or someone who simply enjoys reading and learning.
Mudolo is for all of them.
Starting with simplicity
One of my earliest decisions was to keep Mudolo's interface simple.
The platform brings together several disciplines, each with different ways of creating and sharing work. Developers need ways to present code. Writers need space for long-form publishing. Designers need visual presentation. Readers need an easy way to discover all of it.
Trying to give every discipline a completely different experience from the beginning would have made the platform unnecessarily complicated.
Instead, I approached the first major launch with a shared, welcoming interface.
I wanted someone visiting Mudolo for the first time to understand how to use it without having to learn an entirely new system.
This doesn't mean I want every discipline to look or behave the same way forever. The longer-term idea is to give each creative field its own environment while keeping everything connected through one platform.
For now, simplicity is a deliberate product decision, not a lack of ambition.
Building Mudolo
Mudolo has also been an opportunity for me to work across the different layers of software development.
The frontend uses React, TypeScript, and Tailwind CSS, giving me a component-based foundation for building consistent interfaces.
For the backend, I've worked with Python, Flask, SQLAlchemy, and Alembic, separating application logic into manageable components and handling database models and migrations.
The data layer involves PostgreSQL, with work around database structure and the transition from an earlier SQLite setup.
The wider technical work has included deployment planning, API integrations, authentication-related architecture, and thinking about how the platform can grow without becoming difficult to maintain.
What interests me most about this process isn't simply getting individual features to work. It's understanding how the decisions made in one part of a system affect everything else.
A publishing platform might appear straightforward from the outside, but supporting different forms of creative work introduces questions about content structure, permissions, discoverability, performance, and how users interact with one another.
Those are the kinds of problems I want to continue working on.
Designing for different kinds of people
Mudolo sits somewhere between a publishing platform, a creative community, and a technical product.
That makes its design particularly interesting to me.
I don't think developers, writers, and designers should have to change the way they think about their work just to participate in the same community.
At the same time, a platform needs consistency. People should be able to move between reading an article, exploring a design project, and discovering a developer's work without feeling as though they've entered three unrelated websites.
My approach has been to establish a common visual language first, then build more specialized experiences around it.
I want the interface to support the work rather than compete with it.
What building it has taught me
One of the biggest lessons from working on Mudolo is that building a product involves much more than writing code.
It's easy to think about features individually. A publishing editor, a user profile, a discovery page. Each seems manageable on its own.
The difficult part is making those features work together as a coherent experience.
I've also become more conscious of the relationship between technical flexibility and product simplicity.
A system can be sophisticated internally without requiring users to understand that complexity. In fact, I think some of the most important engineering decisions are the ones users never notice.
Working independently has also pushed me to think beyond implementation. I have to consider how something is designed, how it behaves, how it might fail, and whether it actually makes sense for the people using it.
I'm still learning how to make those decisions well.
What's next
The first major release is about establishing Mudolo's foundation: a shared place for people across creative and technical disciplines.
From there, I want to explore more specialized experiences for developers, writers, and designers.
For developers, that could mean richer code presentation and technical publishing tools. For writers, better long-form reading and publication experiences. For designers, more flexible ways to present visual projects and creative processes.
I'm also interested in how discovery can help people encounter work outside their usual professional circles.
A developer might find inspiration in an essay. A designer might discover an open-source project. A student might come across someone working in a field they hadn't considered before.
That's the kind of interaction I want Mudolo to make possible.
I don't see Mudolo as a finished idea. It's something I expect to keep changing as I learn more about the people who use it and the problems worth solving.
The goal has stayed relatively simple: to build a place where creativity in MENA has more room to exist, develop, and be discovered.
Mudolo Studios & MUDESIGN
A creative space for making, designing, and experimenting.
Mudolo Studios is a broader creative space for making, designing, and experimenting alongside the Mudolo platform. MUDESIGN is its design tool: a place where anyone can create carousels and develop visual designs in the browser. This case study looks at that part of Studios, with the carousel workflow as a working example.
- Scope
- Product design · Visual systems · Frontend development
- Built with
- JavaScript modules · SVG · Canvas · Browser storage
- Featured tool
- MUDESIGN beta · The design part of Mudolo Studios
The starting point
I wanted Mudolo Studios to be somewhere people could make things, alongside Mudolo’s focus on publishing and discovery. Studios brings that broader creative ambition together; its design tool is one part of the experience. Within Studios, MUDESIGN gives anyone a place to start creating visual work. The workflow shown here focuses on making a launch carousel.
A carousel needs more than a collection of attractive images. It needs a sequence, a consistent identity, and enough variation to keep the story moving. MUDESIGN brings those decisions into one workspace.
From an idea to ten frames
Onboarding asks what someone is launching, what it is called, and which visual direction to start with. The app creates a ten-frame deck with prompts for an introduction, a problem, an explanation, and a closing invitation. These are editable starting points, not finished copy.
The editor separates shared brand choices from frame-specific content. A brand name, hashtag, logo, and palette establish continuity; each frame can use a different layout, headline, body, and image.
A visual system with room to vary
Six layouts—Statement, Editorial, Quiet, Poster, Split block, and Big number—offer different ways to give text emphasis. A layout can be applied to one frame or across the deck. Palette presets provide a starting point, with individual colors available for adjustment.
The formats include portrait carousel, square, and story dimensions. Headline and body feedback shows how the text fits, helping the writer see the relationship between language and composition before exporting.
Editing without losing the sequence
The live preview and thumbnail strip make individual changes visible in the context of the deck. Frames can be added or removed, images can be included, and undo and redo support experimentation.
Building around the browser
Keeping work on the device
The core workflow requires no account or backend. Deck content is saved to browser local storage, and rendering and export happen on the device. Reloaded decks are validated before rendering so malformed data can be identified. Browser storage can be cleared or blocked, so it is not a substitute for keeping exported copies.
One composition, from preview to export
Frames are rendered as SVG. At export, fonts are embedded to make the SVG self-contained before Canvas rasterizes it into PNG. This addresses a practical browser constraint: an SVG loaded as an image cannot reliably fetch external font resources. Individual frames and ZIP exports are generated locally at 2× resolution.
Managing weight and history
Font loading is grouped so Arabic and editorial typefaces can load when needed. Preview SVGs reuse the page’s fonts instead of embedding font data repeatedly. Undo history stores deck snapshots, coalesces rapid edits, and limits retained history to control memory use when images are present.
What this version demonstrates
The beta provides a working path from a launch prompt to an editable deck, with multiple layouts, branding controls, live previews, local saving, and browser-side export. The implementation details in this case study are grounded in the design tool’s source code.
For this case study, the production build was rebuilt and served locally, and sample text and layouts were changed in the browser. Export is documented here from the implementation; a full export compatibility test across browsers is still needed. No user-testing results or adoption metrics are claimed.
Where Studios goes next
The broader Studios vision includes more open-ended visual creation and a closer connection between making work and publishing it through Mudolo. MUDESIGN is one part of that direction, supporting carousel creation and visual design within the larger Studios experience. More flexible composition, broader device testing, and clearer recovery when browser storage is unavailable are useful next areas to explore.