Belqis

Product Structure · Systems · Design

WhatsApp

Many product problems are not caused by missing features. They are caused by missing structure.

Requirements are rarely the real problem. The real problem is how those requirements are organized.

My work usually begins when a product starts becoming more complex. As requests, workflows, roles, and features accumulate, teams often know what they want to build but not how the product should continue to hold together and expand.

That is usually where I come in: helping turn complexity into product structures that teams can understand, discuss, build, and extend. My work spans operational platforms, SaaS products, marketplace systems, AI products, and internal tools. Project-based collaboration, remote-first, with longer engagement when needed.

Projects

These projects come from different product contexts, but the patterns I pay attention to are often the same.

Structure becomes unclear, complexity grows, requirements compete, workflows drift apart, and teams lose a shared sense of how the product should hold together.

So these case studies are not only about the projects themselves. They are also about how I understand, organize, and work through complexity.

Projects

When I Usually Join

The product already exists, and so do the requirements. The real problems usually begin when complexity starts to grow, or when a new product needs structure from the beginning.

For example:

  • more features, but less structure
  • more requests, but no shared framework
  • longer workflows and higher maintenance cost
  • product and design decisions pulling against each other
  • a team that knows what to build, but not how to organize it

That is usually when I step in. I do not replace product direction. I build enough structure for it to keep moving.

What I Work On

I rarely start from a single page or a single feature. More often, I look at the relationships between them.

How requirements are organized, how information is understood, how workflows connect, how roles work together, and how the system can continue to expand.

These questions all lead back to the same goal: keeping complex products understandable, maintainable, and extensible.

About

I have worked across branding, websites, operational platforms, marketplace systems, SaaS products, and workflow-heavy tools.

Those projects looked very different on the surface, but the underlying problems were often similar: requirements kept growing, complexity kept increasing, and structure kept breaking down.

Over time, I became less interested in individual features and more interested in how those features are organized.

That is why most of my work now sits in product structure, system logic, and complex operational flows, helping teams reorganize growing complexity into product systems that can keep evolving.

From Design to Product

My earlier work began in branding, packaging, websites, and spatial design.

Although the form was different, they were concerned with the same kinds of questions: how information should be organized, how relationships should be defined, and how people make sense of something complex.

Those experiences gradually carried over into product work and became part of how I approach product structure, system logic, and complex flows.

Collaboration

I usually work on a project basis rather than through a traditional employment setup.

Work can be scoped around a specific problem and a defined phase, or continue as the product evolves.

Common Types of Work

Product structure and scope | Workflow design | System logic

Multi-role collaboration design | UI systems planning | Product decision support

Suitable Projects

Operational platforms | SaaS products | Internal tools

Marketplace systems | AI-assisted workflows | Configuration systems

Multi-role products | Workflow-heavy products | Products growing in complexity

They vary by industry, but the pressure points are often similar: requirements expand, workflows multiply, roles increase, and structure starts to break down.

I work directly with founders, product teams, designers, and engineers, without taking on organizational management or administrative responsibilities.

Contact

If your product is going through any of the following:

* more features, but less clarity

* a team that knows what it wants to do, but struggles to align around one structure

* workflows that keep getting more complex and harder to maintain

* product and design decisions starting to affect one another

* a product that is still growing, but becoming harder to extend

then it may be worth talking.

I usually work with products that already exist, are actively growing, and have started to feel the weight of complexity.

A short project outline is enough to start. All conversations are confidential.

Send a brief context →