How I Managed a B2B Platform's Entire Backend Solo — and Why That's Actually Possible with Directus

When I joined SharMarket as CTO, the situation was clear: we needed a production-grade backend for a multilingual B2B platform — a directory of businesses with virtual exhibitions and a modern web presence. Complex content, multiple locales, user roles, AI integrations, a content team, and an SEO strategy — all with a founding team budget that couldn't stretch to hiring even one dedicated backend developer.

I didn't panic. I made a decision.

The Problem with Building From Scratch

The instinct for most developers is to build. Define your schema, write your models, set up your REST or GraphQL layer, handle auth, build an admin panel, wire up file uploads, manage roles and permissions — and then do it all again when requirements change.

That's a lot of work before you've served a single user.

For a startup, that cost isn't just time. It's opportunity. Every week spent building infrastructure is a week you're not shipping features, not validating assumptions, not responding to what the business actually needs.

I've done it the hard way before. This time, I chose differently.

Why Directus

Directus is not a no-code tool. It's a headless CMS that sits on top of your own database — PostgreSQL, MySQL, SQLite — and gives you a full REST and GraphQL API, a real admin UI, granular role and permission control, file management, and a webhook system, all out of the box.

The key decision for me was this: Directus doesn't own your data. Your database is your database. You can query it directly, write raw SQL alongside it, and if you ever outgrow Directus you walk away with a clean schema and all your data intact.

That's not a CMS. That's a backend accelerator.

What it gave me at SharMarket:

• A full content API for our multilingual articles, product listings, and categories — without writing a single controller
• Role-based access control for the content team, management, and API consumers — configured in minutes, not days
• File management with Cloudflare R2 as storage — plugged in through the dashboard
• Webhooks that fired into our queue system for AI processing pipelines
• A usable admin interface that non-technical team members could actually work in

I built the parts that Directus couldn't handle — custom business logic, AI integrations, the Nuxt frontend — and left the rest to a tool designed for exactly this purpose.

What It Actually Eliminated

Two backend developer hires. Conservatively.

Think about what a backend developer's first six months looks like on a project like this: schema design, API layer, auth system, admin panel, file handling, role management, documentation, bug fixes. That's before any feature work.

Directus handed me all of that on day one.

It also eliminated a category of bugs I never had to fight: auth edge cases, permission logic errors, file upload failures. When those layers are tested by thousands of projects before yours, your surface area for problems shrinks dramatically.

What I spent my time on instead: the things that actually differentiated SharMarket. AI-powered translation and content rewriting. SEO automation. A content pipeline that let our team produce at twice the speed with half the people.

Where Directus Falls Short

I'll be honest about this too.

Complex business logic belongs in your own code. Directus is not a replacement for your application layer. Anything that requires conditional logic, multi-step operations, or domain-specific rules needs to live in custom code. Trying to bend Directus flows to handle what should be a service function is the wrong move.

Custom flows can get messy. The built-in flow/automation system is powerful for simple cases but becomes hard to maintain as complexity grows. I kept flows for simple webhook triggers and handled everything complex in our own Express services.

The admin UI is for admins, not end users. If your product users need a custom interface, you're building it in Nuxt or React — Directus is backend infrastructure, not a frontend.

None of these are criticisms. They're boundaries. Knowing what a tool is for is how you use it well.

The Actual Lesson

The lesson isn't "use Directus." It's a broader one about engineering judgment.

The best technical decision isn't always the one that demonstrates the most skill. Sometimes it's the one that eliminates the most unnecessary work so you can focus on what actually matters.

I could have spent three months building an admin panel from scratch. Instead I shipped AI integrations that cut the content team's workload in half. The business noticed the second thing, not the first.

Tools like Directus exist because the problem of "I need a backend with an admin interface" is a solved problem. Solving it again from scratch isn't craftsmanship. It's just expensive.

Know which problems are worth solving from scratch. Build those. For everything else, choose well and move fast.