We Built Our Own Product: What Redod Taught Us About Building Digital Products

Building a SaaS product of our own taught us what client work never could: the decisive advantages are day-one architectural choices, trust beats AI magic, and operating a product shows you the true cost of every small decision. These are the lessons Redod made us pay for ourselves.

Most advice about building digital products comes from the spectator's seat: an agency that delivers and leaves, or a consultant who never lives with his recommendations. We wanted the other side, so we built Redod: an Arabic-first, multi-tenant SaaS platform that pulls customer conversations from every channel into one inbox, designed, built and operated entirely inside Taqweed, with no external client and no handed-down scope.

This article is a stack of invoices rather than a success story. We paid for every lesson in it: one early architectural decision saved us months, and one neglected detail came back as the same support question every week. If you're a business owner weighing a digital product, these are the parts of the journey that no pitch deck shows.

Why we committed to building a SaaS product of our own

An agency that only ships client work never feels the weight of its decisions. The handoff happens, the invoice gets paid, and the product goes to another team that lives with the consequences. You can work that way for years and never see the bill for a single call you made.

Operating your own product flips that. With Redod there is no client to hand things to: every shortcut in the code costs us the late night, every confusing screen sends its questions to us, every pricing decision lands on our table. SaaS product development, and then running what you built, made us pay for our decisions in a currency no contract mentions: our own time.

That's why this article exists: not to say we built a product, but to explain what changed in how we work because we live with one daily.

Build or assemble? The first lesson in building a SaaS product

We could have wired together off-the-shelf tools and reached something workable much faster. We weighed that option seriously, then built from scratch for one reason: the advantages we wanted are architectural decisions you make on day one and cannot bolt on later.

Native Arabic understanding, not translation. A tool built to understand English and then localised will never grasp how Arabic customers actually write. This lives in the foundation or nowhere.

Full control over when the AI speaks and when it stays quiet. Assembling ready tools means inheriting each tool's behaviour and limits; we wanted to own that decision, not rent it.

Transparent pricing with no hidden margins. Every middleware layer in an assembled stack adds a cost the end user eventually pays.

The honest flip side: assembling ready tools is often the right call. If you're still validating demand, or your edge lives in another layer, build the minimum and assemble the rest. Our rule from building Redod, an Arabic SaaS platform, multi-tenant from day one, end to end: build only what differentiates you, assemble everything else.

Design starts from a behaviour problem, not a feature list

Redod didn't start from a feature list. It started from one scene: a small merchant selling on five channels, WhatsApp, Instagram, Messenger, Telegram and email, hopping between five apps, missing questions, answering late, losing sales. Not because the product is weak, but because nobody replied in time. And the global tools either cost more than a young store can carry, or understand English but not how Arabic customers write.

Every design decision afterwards came out of that scene. The main screen is three columns: the conversation list with filters by channel, assignee and status, the thread itself, and a customer-context panel. The origin of every message stays explicit: customer, teammate, or AI. No surprises, no ambiguity.

The lesson now shapes every engagement, and it's the first thing we check in any product request that reaches us: we don't start from "which features do you want?" but from "which behaviour is costing you money today?". The feature list is an output, never a starting point.

The AI lesson: control beats magic

The easiest promise to sell right now is AI that answers everything automatically. We tested that promise on ourselves first, and learned that trust is the real product: the merchant isn't afraid of the AI working. They're afraid of it speaking in their name, wrongly, in front of a real customer.

So we built control before intelligence. Redod runs on three levels:

The level is set per channel or even per conversation, never one switch for everything. Above it sits the AI teammate: each department gets its own assistant with its own persona, model and provider, and when it detects frustration or a complex request, it hands over to a human instead of improvising.

Our takeaway for anyone building a product around AI: don't ask "how much can it do?". Ask "how precisely can I control what it does?".

What operating a product teaches that designing one never will

Designing a beautiful screen is one thing; answering its users' questions every day is another discipline. The operating half of running our own product exposed a cost that never shows up in design files: the small inconsistency. A button that behaves slightly differently on two screens looks like nothing in a demo. Operating a digital product turns it into the same support question every week until someone fixes it.

Edge cases we used to defer in client work became daily life: a customer writing in an unexpected dialect, an automation firing at the wrong moment. That's why Redod's visual automation engine, a drag-and-drop canvas of triggers and stackable steps, ships its blocks with sensible defaults: a flow has to run on the first try, because we've watched what happens when it doesn't.

This changed our practice as a UX design agency more than anything else. We now build the design system before the screens, not after, because we've personally paid the bill for every inconsistent component. Consistency stopped being a preference; it became a cost line we know by feel.

What this means when you're choosing a partner for your product

Everything we learned from building and running Redod converts into screening questions for you. Ask them of any partner you're evaluating, us included:

Have you lived with a product you made? Not "have you delivered projects?" but: have you operated one and paid for its decisions yourselves? The difference shows in how a team weighs details and how honestly it warns you.

What will you build for me, what will you assemble, and why? A serious partner defends assembling where it's right, and never sells you ground-up construction just because it bills better.

Where does the AI stay silent in your proposal? Anyone offering to automate everything has never run AI in front of real customers for a single day.

Which decisions become impossible to change later at a reasonable cost? Ask for the architectural calls that get locked in the first month. Whoever answers quickly has lived it; whoever says "everything is adjustable" hasn't.

Arabic-first: building a product in Saudi Arabia and the Gulf is its own discipline

Building a product for e-commerce in Egypt and the Gulf taught us that Arabic-first is a different discipline from localising a global tool. Arabic customers don't write the way translated tools assume: they write in dialect, mix numerals with letters, and send one question as three short messages. A tool whose understanding was built for English stumbles here daily, however polished the translation.

Take a merchant in Jeddah selling through WhatsApp and Instagram: her customers ask in colloquial Arabic at nine in the evening and decide to buy within minutes. A product that understands the question and knows when to reply automatically and when to alert a human isn't a nice-to-have here. It's the difference between a sale that closes and one that quietly disappears.

So we tell anyone planning on building a product in Saudi Arabia or around it: make Arabic an architectural decision from day one, in text understanding, in components, and in the AI's own tone. A translation can catch up with a product later. Understanding never does.

Related reading: custom software, ui/ux design.

Market data: Statista — Saudi Arabia Digital Economy.