Tools
TamDone is an Arabic-first project management platform designed for teams across the Middle East and North Africa. Born from the internal frustration of two companies, Takiacademy and Softylines, it addressed a specific market gap: enterprise-grade project management built for RTL languages and Arabic workflows from the ground up.
The product existed since early 2022 as an internal tool solving real cost problems for both companies. When I joined the redesign effort in 2024, TamDone had already validated its core value prop but was constrained by design debt. My role expanded from a redesign mandate to leading all design decisions, working alongside a 12-person engineering team and a newly formed marketing group. The timing was critical: the company was pivoting from internal tool to commercial SaaS, and the design had to reflect that ambition.
The original design was fundamentally broken for production. It was pure graphic design: beautiful mockups filled with overlapping elements, no component thinking, and layouts that could not translate to responsive HTML.
Developers spent weeks reinterpreting pixel-perfect designs that bore no resemblance to how the web actually works. The design system was nonexistent; every screen felt bespoke, every request required re-solving the same problems.
Beyond the internal friction, the business problem was acute. Takiacademy alone needed project management for 150+ users, and countless teams across the region faced the same cost burden. Worse, no existing solution handled Arabic properly. ClickUp and Asana treated Arabic as an afterthought: RTL support was clunky, terminology did not translate cleanly, and the experience felt foreign to native speakers.
The core issue: teams everywhere needed to coordinate work, but no tool was built for them.
The primary goal was unambiguous: cut the cost of project management software while building something functionally complete enough to serve as Takiacademy's replacement for ClickUp. Secondary goals shaped the product's identity: add native Arabic support and create a friendlier experience for RTL layouts than anything on the market.
Success would be measured in two ways. First, internal adoption: the product had to be useful enough that both companies could run entirely on TamDone. Second, external traction: if we could convince external clients, starting with partners like Softy Skills and Osthedy, to use it, we would validate a path to revenue.
I conducted broad discovery across the user base. Over 30 responses per survey came back from teachers, administrators, developers, and team leads. The pattern was immediate and humbling: developers were not following the designs because they were unrealistic. They would rationalize, cut corners, or build approximations rather than implement unmeasurable mockups. This was not laziness; it was survival. The designs existed in a different medium than code.
Competitive audit of ClickUp and Asana revealed a familiar story: both had borrowed heavily from linear, Western workflows. Neither handled RTL layouts naturally. Neither understood the cultural or linguistic nuances of MENA teams. The terminology felt borrowed and stiff in Arabic.
The most important finding shaped everything that came next: the old design had no component library and no design system thinking. Every screen was unique. This was not a problem to patch. It was a foundation to burn and rebuild.
I started by meeting with the engineering team to map what already existed and what would need rebuilding. We identified the features with the highest leverage: task creation, timeline views, team collaboration, and notifications. Those became the first redesign targets while engineering continued incremental improvements to the rest of the product.
The design direction was informed by one unavoidable fact: the founder and team had lived with ClickUp for years. It was near-perfect for their use case. The risk of designing away from that pattern seemed higher than the risk of being too similar. But copying ClickUp directly was a trap. We needed to borrow its patterns where they worked, then intentionally diverge where Arabic, RTL, and cultural context demanded it.
The pivotal moment came when the redesign went live in production. Suddenly, hypothetical problems became real. Users surfaced edge cases we had not considered. The design patterns that looked elegant in Figma revealed tiny friction points in actual workflows. Feedback was brutal, but it was also precise: we knew exactly what to fix.
Throughout this phase, I had to make hard tradeoffs between my design vision and engineering feasibility. Several times, I redesigned a UI element not because it was wrong, but because the dev team had found a simpler path that was 85% as good and 10x faster to ship. That taught me something crucial: design elegance is not always the limiting factor.
The largest decision was architectural: build a production-grade design system from scratch. I came from a mobile development background, which meant my first instinct was to follow Material Design guidelines and naming conventions. That was a mistake. Material is built for left-to-right, vertical-stacking-first interfaces. Forcing it into an RTL platform created constant friction.
After months of pain, I pivoted to Ant Design's paid design system, which had better RTL affordances and a more flexible token structure. The migration was brutal. We had already implemented Material variables and components across the codebase. Changing systems midway meant finding alternatives for nearly every token and reworking component APIs. But the payoff was worth it: by the time we stabilized on Ant Design, the design system became coherent enough that engineers could predict patterns instead of waiting for specs.
The handoff process evolved alongside the system. Early on, I created detailed Figma specs. As the design system matured, I shifted to documenting design tokens as CSS variables and focusing pairing sessions on edge cases rather than every detail. This freed up engineering bandwidth and made the design system the source of truth, not the spec file.
snippet.txt
:root {--color-primary: #3b82f6;--spacing-unit: 8px;--radius-control: 10px;--font-body-ar: "IBM Plex Sans Arabic", system-ui, sans-serif;--text-direction: rtl;}
The quantified outcomes speak clearly. TamDone grew to serve 300K+ students trained, with over 100K tasks created daily across the platform. Enterprise adoption followed: 30+ corporate projects were launched on TamDone, with companies like Takiacademy, Softylines, Softy Skills, and Osthedy running their operations entirely on the platform. The 40% reduction in missed deadlines reported by users reflected a real change in how work got coordinated.
More importantly, every one of those client wins came with total Arabic support, something neither ClickUp nor Asana could offer. When Softylines and partner companies attended events across the MENA region, they could honestly say their platform was built for Arabic teams, not retrofitted for them.
The business impact was equally real. Both companies eliminated their ClickUp dependency, and TamDone became a differentiated asset for MENA enterprise conversations. But I was disappointed by the business side. Most clients came through existing partnerships and relationships, not through viral adoption or outbound sales. We built a product "for everyone," but market penetration stayed concentrated among our network. That is a business lesson, not a design failure, but it stung.
The single most important lesson I learned hits harder now than when I first understood it: business execution beats product perfection. No matter how elegant your design or how complete your feature set, a weak go-to-market motion will slow the product down. We had a genuinely useful platform, but we did not have a distribution engine. That asymmetry taught me that product design is only part of the outcome; the rest lives in sales, positioning, and market timing.
Second, I would approach scope completely differently if I started today. We built a full project management system before we had validated which slice customers would pay for first. I would have shipped the thinnest viable MVP possible, maybe just task management and commenting, gotten it to customers immediately, and let them tell me what to build next.
Third, mentoring gaps hurt. I came into this role as a lead without having led before. I knew design, but I did not know design systems at the scale we needed. Having a senior designer or design systems expert as a sounding board would have compressed that learning curve by months.
The natural next phase is obvious in hindsight: aggressive go-to-market alongside selective feature expansion. Instead of building every feature competitors had, TamDone should double down on the features that make it irreplaceable for MENA teams: deeper Arabic workflow support, localized templates for specific industries, tighter integrations with popular regional business tools, and clearer enterprise positioning.
Open questions remain. Why has the product not grown faster? Is it a problem of distribution, positioning, pricing, or market readiness? Is there truly demand for a ClickUp alternative among teams that do not already know TamDone exists?
I am no longer working at the company, but the product is very much alive and under active development. What I would love to see is the team invest heavily in understanding why existing happy customers do not refer others. That insight could unlock the next phase.
The hard part of building a product is never the product. It's believing in it enough to sell it relentlessly.
