Build Systems That Help Other People Build

If you look at a command-line interface for an enterprise data platform, a grassroots technology nonprofit in a small town, and an Arabic community practicing with AI agents, they look like three unrelated worlds.

To me, they are the same problem at three different scales.

In each case, talented people want to build something useful, but too much of their energy is consumed by friction they should not have to solve alone. The developer is clicking through twenty portal screens to automate a repeatable workspace task. The young founder in a peripheral town has the skill to build a product, but no local peers, mentors, or physical place to start. The Arabic-speaking professional sees new AI tools every week, but lacks a practical environment to turn them into daily capability.

When you see that pattern, you have two choices:

1. Build one finished solution for one person at a time.
2. Build the rails that let hundreds of people build their own.

Over the last fifteen years, every meaningful project I have worked on has come down to choosing the second path.

1. Find the shared constraint, not the loudest symptom

When people struggle to build, the visible symptom is rarely the real bottleneck.

Early in Hasoub, the visible symptom was “there are not enough tech startups in our towns.” If you treat that symptom directly, you run a weekend pitch competition and wonder why nothing survives six months later.

The actual constraint was upstream: people who wanted to build had never met each other in the same room, had no local role models who looked like them, and had no place where trying and failing was normal. Once we treated belonging, peer density, and physical space as the shared infrastructure, people started building companies, study groups, and programs we never had to design centrally.

The same principle applies inside software platforms. When developers ask for dozens of one-off buttons in a web UI, the underlying constraint is often that the platform cannot be scripted, versioned, or composed from a terminal. Give them a clean command-line interface (fab) and an open context layer (MCP), and they compose workflows the product team never had to anticipate.

2. Design interfaces that both humans and agents can compose

We are living through a fundamental shift in who uses our systems.

For decades, we built software assuming a human sitting in front of a screen with a mouse, or a developer writing rigid integration scripts against raw REST endpoints. Today, a third actor sits beside them: an AI agent working on the human’s behalf.

An AI agent struggles with deeply nested menus and undocumented side effects for the exact same reasons a new developer does. Conversely, when a system exposes:

• Clear verbs and predictable nouns (like file-system paths in a CLI)
• Explicit context and schemas (like Model Context Protocol tools)
• Safe, inspectable state transitions (preview before apply, clear error messages)

something remarkable happens: the system becomes easier for humans to learn and drastically more reliable for AI agents to operate. Good platform ergonomics and agent readiness are not competing priorities. They are the same discipline.

3. Lower the floor, raise the ceiling

My favorite tools and institutions share one design property: they make the first step takes minutes, without capping how far you can go.

When we built ScratchDuino years ago, the goal was to let a ten-year-old snap a sensor onto a magnetic board and see their code move the physical world in five minutes, while still allowing older students to program real robotics logic.

When we run weekly live sessions at the Arab AI Club today, we follow the same rule. Nobody needs another two-hour theoretical lecture about how transformers work before they are allowed to build. We start by shipping a real workflow together in the first twenty minutes, then open the hood so builders can customize, critique, and extend it for their own work.

If the floor is too high, only specialists enter. If the ceiling is too low, people outgrow the system the moment they become capable.

4. Distribute ownership early

A system that requires its creator to be in every room is not a system yet. It is a bottleneck with a title.

Whether you are building an open-source directory like Hasanat.dev, a community catalog like UmmaHub, or a multi-program institution like Hasoub, durability comes from making contribution legible:

• Make the standard visible: Show what a good contribution looks like in concrete examples, not long rulebooks.
• Keep the unit of contribution small: A person should be able to add value in thirty minutes without needing permission from a committee.
• Give real credit and real stewardship: People care for what they co-own.

The builder’s test

Whenever I evaluate a new product, tool, or initiative now, I ask one question before any other:

If this succeeds, does it merely impress people, or does it leave them more capable of building without me?

The best products do not turn users into spectators. They turn spectators into builders. Build the rails, clear the friction, share the tools, and let people surprise you with what they create.