Coder Legion - Recent posts tagged developer-stories

Kevin Martinez on Building, Learning & Growing as a Developer From Ideas to Impact

Mon, 05 Oct 2026 20:09:46 +0000

In this Developer Spotlight, Tom Smith sits down with Kevin Martinez for a relaxed conversation about his journey as a developer, his experiences, and the perspectives he has gained along the way.

No scripted success story. No corporate pitch. Just two developers having a real conversation about the journey behind the work.

🎥 Watch the Developer Spotlight

Watch the full conversation on YouTube

Meet Kevin Martinez

Kevin Martinez joins Tom for this Developer Spotlight to share his experiences and perspective as a developer.

The conversation offers a chance to hear directly from Kevin about his journey, the experiences that have shaped him, and the lessons he has picked up along the way.

View Kevin Martinez's CoderLegion profile

A Conversation About the Developer Journey

Developer journeys rarely follow a straight line.

Behind every developer are years of learning, experimenting, solving problems, making mistakes, changing direction, and discovering what kind of work they genuinely enjoy.

In this conversation, Tom and Kevin take a relaxed approach to exploring that journey — sharing experiences, perspectives, and the realities behind being a developer.

Watch the full conversation above and hear Kevin's story in his own words.

Meet the Host: Tom Smith

Tom Smith is a member of the CoderLegion community and the host of our Developer Spotlight conversations.

Through these conversations, Tom gives developers an opportunity to share their experiences in a relaxed and authentic format — with the developer and their story remaining at the centre of the discussion.

View Tom Smith's CoderLegion profile

Why We're Starting Video Discussion Stories

Written Developer Stories give developers a place to tell their stories through words.

Video Discussion Stories add something different: a real conversation.

There are no scripted success stories and no requirement to present a perfect career journey. Developers can simply talk about their experiences, the things they've learned, the challenges they've faced, and the work they're passionate about.

The goal is simple:

Real developers. Real journeys. Real conversations.

Developer Spotlight at CoderLegion

Developer Spotlight is part of the CoderLegion Developer Stories series, created to give members of the developer community a platform to share their experiences in their own words.

Each conversation brings together a community host and a developer guest, creating an opportunity to learn from the people behind the code.

Want to Take Part?

Would you like to share your own developer journey with the CoderLegion community?

We're looking for developers with different backgrounds, experiences, interests, and perspectives.

You don't need to have a perfect success story.

Your journey is the story.

If you'd like to take part in a future Developer Spotlight or Developer Story, reach out to the CoderLegion team.

About Kevin Martinez

Kevin Martinez is a member of the CoderLegion developer community.

View Kevin Martinez's profile on CoderLegion

About Tom Smith

Tom Smith is a member of the CoderLegion community and host of the Developer Spotlight series.

View Tom Smith's profile on CoderLegion

CoderLegion Developer Stories

Developer Stories is where CoderLegion members share the experiences, lessons, ideas, projects, and journeys behind their work.

Written stories. Video conversations. Real developers.

Real developers. Real journeys. Real conversations.

Guest: Kevin Martinez
Host: Tom Smith
Series: CoderLegion Developer Spotlight
Format: Video Discussion Story

From Retrenchment to Full-Stack Developer: Wade Thomas on Learning, Simplicity and Building Software

Sat, 29 Aug 2026 09:12:49 +0000

From Retrenchment to Full-Stack Developer: Wade Thomas on Learning, Simplicity and Building Software That Matters

Developer Stories | CoderLegion

What happens when a career change forces you to rethink your future?

For Wade Alister Thomas, the answer was to turn a difficult setback into the beginning of a completely different career.

After spending 18 years working in the telecommunications industry, Wade was among approximately 500 employees who were retrenched in November 2018. He had recently started a family and finished building his home, so the timing could hardly have been more challenging.

At that point, Wade had a decision to make: look for another traditional job or take the small coding projects he had been doing on the side and turn them into a full-time career.

He chose the second path.

Today, Wade is a self-taught full-stack developer and consultant based in Trinidad & Tobago. His preferred stack includes TanStack Start, Tailwind CSS and shadcn/ui on the frontend, with Directus, PostgreSQL and Redis running on a VPS through Coolify.

He also works with businesses on their digital presence, builds applications, creates logos and Git templates, and regularly shares what he learns through technical articles.

In this Developer Stories interview, Wade talks about his journey from telecommunications to software development, the challenges of learning without a traditional curriculum, why he prefers simple and sustainable architectures, what attracted him to self-hosting, and why developers should focus on solving business problems rather than simply using the newest technology.

From 2014 to 2018: When a Career Changed Direction

Wade started coding in 2014, initially taking on small projects for friends and family.

At the time, however, software development was still something he was doing alongside his full-time career in telecommunications.

That changed in 2018.

About 500 employees at the telecommunications company were retrenched on November 15, 2018, and Wade was among them.

It was a particularly difficult period because he had recently started a family and had just finished building his home.

"It was a really difficult time, as I had started a family and just finished building our home."

After 18 years in telecommunications, Wade had to decide whether to look for another traditional job or pursue the coding work he had already started doing on the side.

With the support of his wife and after much prayer, he decided to pursue software development full-time.

That decision marked the beginning of a completely different professional journey.

The Challenge of Being a Self-Taught Developer

Being self-taught gave Wade freedom, but it also created one of the biggest challenges many independent developers face: deciding what to learn.

There was no university curriculum, mentor or structured program telling him which technology to choose next.

He initially enrolled with Treehouse but eventually had to stop because he could not afford the monthly subscription.

He began learning JavaScript, HTML and CSS, purchasing discounted courses on Udemy and experimenting with different technologies.

Eventually, he realized that knowing frontend technologies alone wasn't enough.

He needed to understand backend development as well.

The problem was that there was nobody to point him toward a specific path.

Before AI made technical research much easier, Wade had to search through the internet himself, experiment, make mistakes and figure things out through trial and error.

He eventually settled on React for the frontend and Node/Express for the backend.

But the experimentation didn't stop there.

He explored Vue.js, returned to React, and tried several frameworks including Next.js, Remix, Redwood and TanStack.

Then came another area of exploration: headless CMS platforms.

He experimented with Contentful, Strapi, DatoCMS, Sanity, Storyblok, Prismic, Payload and eventually Directus.

Looking back, Wade says deciding what to learn and sticking with it was a major struggle.

What eventually helped was finding a technology stack with a manageable learning curve and, more importantly, enjoying the process of learning.

The motivation shifted from simply trying to reach an outcome to genuinely enjoying the journey.

Finding a Stack That Works

Wade's current technology stack didn't appear overnight.

It evolved through real client work and the practical problems that came with building software as a solo developer.

His first paying client was a travel agency.

At the time, Wade was using React on the frontend and Node/Express on the backend.

That meant manually building many of the pieces required by the application, including forms, APIs and database functionality.

The workload was significant.

He didn't meet the original delivery date, although he ultimately delivered a working product.

That experience taught him something important about working as a solo developer: the technology stack itself can have a major impact on how quickly and sustainably you can deliver.

Instead of simply accepting the complexity, Wade began researching alternatives.

He wanted technologies that worked well together and allowed him to spend more time building the actual application instead of repeatedly wiring infrastructure together.

His current approach focuses on technologies including:

TanStack Start
Tailwind CSS
shadcn/ui
Directus
PostgreSQL
Redis
VPS infrastructure
Coolify

The goal isn't to use the most impressive stack possible.

It is to use a stack that works well for the types of clients he serves.

Because Wade primarily works with startups and small-to-medium businesses, he doesn't believe every project needs an enterprise-level architecture.

Instead, he looks for solutions that are affordable, sustainable and fast to deliver.

Why Wade Chose Self-Hosting

Many developers today immediately reach for managed platforms such as Vercel or Netlify.

Wade took a different route.

He initially used Netlify for some of his projects, but eventually became frustrated with aspects of the platform, including pricing, DNS management and deployment errors that weren't always intuitive.

The possibility of unpredictable hosting costs also made him cautious about some managed platforms.

Self-hosting offered a different model.

With a VPS and Coolify, Wade could control the hosting environment while still keeping much of the convenience developers expect from modern deployment platforms.

He could create subdomains, automatically manage SSL certificates, run frontend and backend applications on the same server, and deploy directly from GitHub.

For the types of businesses he works with, this provided a practical balance between flexibility, cost and simplicity.

But Wade sees another important benefit to self-hosting.

It forces developers to understand what actually happens when an application runs in production.

You have to understand the server, deployment process, database and infrastructure.

That knowledge can be valuable even when working with managed platforms.

For Wade, predictable costs are another major advantage.

Instead of worrying that an unexpected traffic spike or usage metric could suddenly increase a hosting bill, he knows what infrastructure he is paying for.

Self-hosting also reduces dependence on a particular provider's pricing and platform rules.

At the same time, Coolify provides many of the conveniences developers appreciate from managed platforms while allowing Wade to retain control over his infrastructure.

Why Directus Became an Important Part of His Stack

Before using Directus, Wade built backend systems using Node/Express.

That meant creating APIs, middleware, authentication and authorization himself.

For a solo developer, that can add a considerable amount of work to every project.

Directus changed that equation.

With Directus, Wade could quickly create a backend and automatically expose APIs through REST, GraphQL or the SDK.

The platform also provides a data studio that allows clients and non-developers to manage their own data.

Authentication is available out of the box, and Directus can connect to existing SQL databases.

For Wade, this makes Directus particularly useful for content-driven websites and fast-turnaround MVPs where speed and a client-friendly data management experience are important.

It also fits naturally into his self-hosting approach.

However, Wade doesn't see Directus as the answer to every backend problem.

For applications with highly complex business logic, he believes a custom backend can still be the better choice.

That distinction is important.

The goal isn't to find one technology that solves every problem.

The goal is to choose the right level of complexity for the problem being solved.

When Simplicity Becomes an Architecture Principle

One of the strongest themes in Wade's approach to development is simplicity.

Developers can easily become distracted by the desire to build something technically impressive.

Modern frameworks, animations, advanced architectures and new technologies can all be exciting.

But they can also distract from the actual purpose of a product.

Wade believes in launching a minimum viable product, keeping the initial implementation focused and adding complexity only when it becomes necessary.

Complexity has a cost.

It can increase:

Bugs
Development time
Testing requirements
Maintenance work
Project costs
Time required to get customer feedback

He experienced this mindset firsthand while building his own portfolio.

His initial idea was to create an impressive interactive website with transitions, parallax scrolling, dark mode, 3D images and animations.

Instead, he stepped back and asked what the portfolio actually needed to accomplish.

The purpose was simple: convince a potential client that he could build software that solved real-world problems.

So he created a much simpler interface and focused on examples of applications he had built.

The result was a faster launch and a clearer demonstration of his actual capabilities.

The lesson was simple:

A product doesn't need to demonstrate everything a developer knows. It needs to solve the problem it was created to solve.

From Developer to Consultant

Working directly with clients changed Wade's understanding of software development.

As a developer, it's easy to focus primarily on code.

But clients aren't usually buying code.

They're buying a solution to a business problem.

Wade learned that understanding the client's industry, customers and business goals is just as important as understanding the technology.

A web application is often not the business itself.

Instead, it becomes a tool that helps the business compete, communicate with customers or operate more effectively.

That means technology decisions should follow business requirements rather than dictate them.

Wade puts it simply:

"The technology must serve the solution, not the other way around."

This also means that the technically superior solution isn't always the right solution.

Sometimes the newest or most advanced technology is also the most expensive.

If that cost doesn't make sense for the business, Wade would rather recommend a proven and affordable solution.

The best architecture isn't necessarily the one with the most impressive technology.

Sometimes it is the one that makes the most sense for the business.

Building More Than Software

Wade's work extends beyond writing code.

He also works with UI/UX, ecommerce, performance, authentication, security, branding and logo design.

For him, understanding the user is a critical part of building software.

He gave the example of working with an ecommerce client selling natural self-care products.

Rather than immediately starting with the interface, Wade became a customer himself.

He bought and experienced the products, visited the client's pop-up events and observed the customers.

That helped him understand the product, the customers and the image the business wanted to communicate.

He could then use that understanding to shape the user interface and create a persona for the ideal customer.

This reinforced an important lesson:

A technically flawless application is not necessarily a successful product.

If nobody wants to use it, the quality of the code doesn't matter nearly as much.

Why Wade Shares What He Learns

Wade's development journey wasn't always easy.

There were periods when he almost gave up.

One of the challenges he faced was the cost of education and development resources, particularly because of currency conversion. At one point, the exchange rate made many courses difficult to afford.

He also remembers a time before AI made technical research much easier.

Finding reliable information required significant searching and experimentation.

That experience influenced the way Wade approaches sharing knowledge today.

His goal is straightforward:

Share the tools he uses, explain why he uses them, and show others how to use them.

He wants to make the learning curve easier for someone who might be considering web development as a career path.

There are now countless frameworks, platforms and tools available, and that abundance can itself become overwhelming.

Wade wants his content to help developers make sense of those choices rather than simply telling them which technology is "the best."

Teaching has also improved his own understanding.

Explaining a concept forces you to understand it more deeply.

For Wade, documenting his learning has therefore become part of his own development process.

The more he teaches, the better he understands the technologies he works with.

Advice for Self-Taught Developers

For developers starting their journey today, Wade has a few practical recommendations.

First, choose a programming language with a strong community and learn the fundamentals well.

Don't make learning feel like a punishment.

There will always be difficult periods, but there should also be some enjoyment in the process.

Second, take advantage of the huge amount of free educational material available today.

YouTube has become a valuable learning resource, and AI can also be used as a learning assistant.

Wade recommends exhausting free resources before spending money on courses.

Third, use development roadmaps.

One of the biggest challenges he faced was not knowing what to learn next.

Today, developers have access to many structured roadmaps that can provide direction.

Perhaps most importantly, Wade recommends avoiding the temptation to become a jack of all trades.

Find a technology stack you enjoy and become highly capable with it before constantly adding new technologies.

Don't chase every new framework simply because it is popular.

Change technologies when there is a real reason to do so and when the change genuinely improves your development process.

And when building applications, focus on structure rather than obsessing over syntax.

Before writing code, understand what you want to achieve.

Break the application into components and understand how those components need to interact.

Then start writing the code.

As Wade puts it, understanding structure can eliminate many of the problems that inexperienced developers encounter.

A Journey Built on Learning and Purpose

Wade's journey from telecommunications to full-stack development wasn't planned in a traditional way.

It began with small coding projects, continued through a difficult career transition, and developed through years of self-directed experimentation.

Along the way, he learned that technology is only one part of software development.

Choosing the right tools matters.

Understanding infrastructure matters.

Learning continuously matters.

But understanding the business, the customer and the problem you're trying to solve may matter even more.

His approach today reflects that experience: choose practical technologies, avoid unnecessary complexity, control infrastructure where it makes sense, understand the user and keep learning.

For developers who feel overwhelmed by the constant stream of new frameworks and technologies, Wade's story offers a useful reminder:

You don't need to learn everything. You need to learn enough to solve meaningful problems well.

And perhaps his most personal piece of advice comes from the principle that has helped him throughout the journey:

"As for my secret weapon — whenever I'm stuck looking for a solution, I pray."

About Wade Alister Thomas

His coderlegion profile

Wade Alister Thomas is a self-taught full-stack developer and consultant from Trinidad & Tobago.

His preferred technology stack includes TanStack Start, Tailwind CSS, shadcn/ui, Directus, PostgreSQL, Redis and Coolify-managed VPS infrastructure.

Through Northern Range Digital, he helps businesses establish their online presence and build digital products. He also creates logos and Git templates and regularly shares what he learns through technical articles and guides.

You can learn more about Wade and his work through his CoderLegion profile and website.

Developer Stories: Jaafar on Building Reliable Systems for Arabic Newsrooms

Mon, 24 Aug 2026 01:25:35 +0000

Developer Stories: Jaafar on Building Reliable Systems for Arabic Newsrooms

Developer Stories is a CoderLegion series highlighting the real journeys, challenges, lessons, and experiences of developers building software in the real world.

For this edition, we spoke with Jaafar, founder of ManTek Technologies in Dubai, about his journey from studying IT engineering and AI at Damascus University to working with AWS, WordPress, and high-traffic publishing systems.

Rather than focusing on a traditional career timeline, this conversation explores something developers often learn only through experience: the difference between systems that appear to work and systems that can actually be trusted.

From silent failures and Arabic-language challenges to scaling WordPress and building NUZ, Jaafar shares lessons learned from working with production systems where mistakes can become visible to thousands—or millions—of users.

From Damascus University to ManTek

Jaafar studied IT engineering with a focus on AI, which he describes as involving a lot of statistics and not much of what he eventually ended up doing professionally.

His path into technology and media took him to the UAE, where he joined Al Khaleej Newspaper.

Publishing has a rhythm you do not appreciate from outside: it never pauses, the deadlines are real, and when something is slow or wrong it is wrong in public.

That experience led to work with a television channel in Dubai Media City, where the systems became considerably deeper and the scale considerably larger.

AWS was already part of the technology stack when he arrived.

Rather than learning cloud technology through tutorials or isolated projects, he learned it while working on systems carrying real traffic.

AWS was already the stack when I arrived there, so I learned it the useful way, on a system that was already carrying real traffic.

For Jaafar, that became one of the biggest additions to his career.

WordPress came later, and interestingly, the reason wasn't primarily technical.

Management had decided to move away from depending on in-house systems.

Bespoke platforms can be expensive to build and maintain, while also creating a significant learning curve whenever a new developer joins the team.

WordPress offered something different: a platform developers already knew and could extend.

I think that reasoning is underrated.

Eventually, ManTek Technologies grew out of Jaafar having enough experience to be useful on his own, combined with a backlog of ideas he had been carrying around for years.

At some point, building those ideas became more interesting than leaving them unbuilt.

When Systems Fail Quietly

One of the recurring themes in Jaafar's work is silent failure.

A system that crashes is usually obvious.

A system that confidently gives you the wrong answer can be much more dangerous.

Because a failing check tells you it failed. A blind one hands you a clean, confident, wrong answer and lets you act on it.

One example came while auditing structured data on his own website.

A profile URL appeared to be returning a "Page not found" response. After checking it in a real browser and running automated checks for common bot-blocking behaviour, everything appeared normal.

So he removed the URL from twenty-two pages and began preparing the commit message.

Then he discovered the problem.

The profile actually existed.

The platform was simply serving logged-out visitors a page saying that it did not.

Nothing had timed out. Nothing had crashed. The check had not reported an error.

It had accurately reported the page it had been given—even though that page itself was misleading.

The instrument had not errored. It had truthfully reported on the page it was given, which happened to be a page about not finding things.

Once he recognised the pattern, he found five more examples in the same week.

There was an API field answering a different question than the one he intended to ask. A list endpoint disagreed with its own item endpoint. An analytics beacon could not be detected with curl for two independent reasons.

There were also editors that accepted a save and appeared to complete the operation while nothing actually reached disk.

That last failure was particularly painful.

A fully reviewed Arabic translation—forty-eight changed lines—existed nowhere except inside a browser tab.

The important lesson wasn't that these problems were technically difficult.

They weren't.

The danger is not that these are hard to fix. Every one was trivial to fix. The danger is that nothing asks you to look.

The 404 That Wasn't

Building for Arabic

One of the biggest challenges developers can underestimate when building for Arabic is that many assumptions in software were never explicitly written down.

That means when those assumptions break, the system may not necessarily tell you.

Jaafar highlights several examples.

Arabic URLs and Byte Limits

WordPress caps a new URL slug at 200 bytes in core through utf8_uri_encode( $title, 200 ).

For English, that budget roughly corresponds to 200 characters.

Arabic is different.

Because Arabic characters can require approximately six bytes after percent-encoding, the same limit can translate to roughly thirty-two characters.

A normal Arabic headline can exceed that easily.

The result can be a URL silently truncated in the middle of a word.

Even more concerning, this can affect URLs that have already been published.

Search

Arabic search introduces another class of problems.

WordPress search uses LIKE '%term%' over the post table, comparing raw bytes.

But Arabic contains optional diacritics, multiple written forms of letters such as alef and hamza, and characters such as tatweel, which can stretch a word without changing its meaning to a reader.

On a real archive containing 250,000 articles, Jaafar compared a search for:

مُحَمَّد

The results were striking:

Search across 250,000 articles	Results	Time
WordPress	1	4.8 s
With normalisation and an index	28,238	0.55 s

One result instead of more than twenty-eight thousand.

And again, there was no obvious error.

The editors experiencing the problem didn't necessarily report that search was broken.

They reported that it was slow.

Slow is the part you can feel.

Rendering Arabic

The challenges don't stop at encoding and search.

Jaafar also encountered an issue while generating images containing Arabic text.

He kept anchoring the text to the wrong edge.

The relevant attribute was text-anchor, where start does not necessarily mean "left". It means the start of the reading direction—which, for Arabic, is the right.

The library was behaving correctly.

His intuition was wrong.

The general lesson: if you build for a language you do not read, your tests will share your assumptions. Test with real content from real users.

WordPress Arabic Search

Scaling WordPress

Jaafar has worked with genuinely large Arabic newsroom traffic, and his lessons about scaling WordPress are less about simply throwing more resources at the application.

He identifies three major lessons.

The spike is rarely the interesting problem

A 20x traffic surge on a news story can sound terrifying.

But much of that traffic consists of identical anonymous requests that can be handled by caching.

The more interesting problems are the requests that cannot be cached.

Search.

Logged-in editorial traffic.

And the write path that still needs to publish content while everything else is happening.

Jaafar also makes an important clarification about the often-mentioned 50,000 concurrent-user figure:

It is load-tested, not an observed peak.

The test demonstrates that the cacheable path can hold up.

It says much less about the newsroom itself—and the newsroom is the part that keeps you awake.

Background jobs fail quietly

WordPress cron is another potential weak point.

Because cron is triggered by traffic, putting WordPress behind a load balancer can result in cron running on every server simultaneously—or on none of them.

Scheduled posts can fail to publish without necessarily producing an obvious alarm.

"Nothing happened" is not an event.

This is why one of Jaafar's open-source plugins elects a single cron runner across a fleet and raises an alert when it stalls.

Move work away from WordPress

Media processing is a good example.

Serving and resizing images directly from the application means the application is doing work that doesn't necessarily belong there.

Moving that work to object storage and an edge layer means the origin server becomes less sensitive to traffic spikes.

After five years of working with large-scale Arabic newsroom traffic, Jaafar sees a consistent pattern:

Uptime comes from having less of the system in the request path, not from tuning what is in it.

The Importance of Observability

For Jaafar, observability is slightly different from simply having logging and monitoring.

A system can have both and still fail silently.

The question he cares about is:

Can a check distinguish "this is fine" from "I cannot see this"?

Many systems cannot.

An uptime monitor hitting a homepage can tell you that the homepage renders.

It cannot tell you whether scheduled posts were published, whether email actually left the system, or whether search returned the correct records.

He experienced this distinction on his own website when two analytics counters for the same site and period disagreed by roughly two orders of magnitude.

Neither system was broken.

Neither was lying.

They were simply answering different questions.

One counted every request reaching the edge, including bots.

The other counted browsers that actually executed the measurement script.

Only one represented the number of people reading the site.

Using the wrong number would have overstated readership by approximately eighty times.

Before you trust a number, know what it counts. That is observability too, and it is the part nobody writes runbooks for.

His approach is therefore to alert on outcomes users would actually notice rather than simply monitoring whichever signal is easiest to collect.

Failures should be loud by design.

One of his plugins, for example, refuses to send mail when it is misconfigured rather than silently falling through to a transport that appears healthy but delivers nothing.

Refusing is friendlier than pretending.

Open Source and Real-World Problems

Jaafar has now released five open-source projects, each connected to the real-world problem that led to it.

For him, the connection between the diagnosis and the fix is important.

The fixes themselves are often small.

For example, wp-arabic-slug-schema-guard addresses the byte-budget problem around Arabic WordPress slugs.

But the valuable part isn't just the code.

It is understanding why the problem exists.

WordPress truncates at 200 bytes.

Arabic can consume approximately six bytes per character.

And published slugs can potentially be rewritten underneath an existing site.

A fix without that context is a snippet nobody trusts. The context without a fix is a complaint. Publishing both together is the only version that is actually useful to the next person.

The plugins are deliberately implemented as must-use plugins rather than ordinary plugins.

The reason is that infrastructure such as cron election and mail transport should not be something that can simply be switched off from an administrator screen.

There was even a lesson in the packaging of the plugins themselves.

Several plugins declared:

"type": "wordpress-muplugin"

so that Composer could install them into the correct directory.

But two of them did so without requiring composer/installers, the package responsible for interpreting that type.

In projects that already included the dependency, everything worked.

Elsewhere, Composer reported a successful installation but placed the plugin in vendor/, where WordPress never loaded it.

The installation succeeded.

The plugin simply did nothing.

Which was, ironically, exactly the kind of silent failure the plugins were designed to prevent.

What I learned from releasing them: the environment is the bug, almost every time.

Across six rounds of adversarial testing on one of the projects, every bug discovered involved either a check that could not fail or a silent wrong answer.

And none of those bugs were found simply by reading the code.

ManTek Technologies on GitHub

Building NUZ

Jaafar is currently developing NUZ, a cloud-native publishing platform aimed at high-traffic newsrooms.

He is careful to clarify its current status:

NUZ is pre-release. I am building the core, and there are no external partners on it yet.

That distinction matters.

The project is not being presented as a platform already running with external partners. It is still being built.

The problem NUZ is intended to address is the way many publishing platforms approach scale.

A newsroom might begin with a CMS designed for a blog.

Then caching is added.

Then a CDN.

Then a media pipeline.

Then a search layer.

Each addition introduces another component and another potential failure mode.

Eventually, the newsroom is maintaining an architecture that nobody originally designed as a whole.

NUZ starts from a different assumption:

The traffic is spiky, the content is Arabic, and the editorial team publishes continuously while all of that is true.

Engineering in the Real World

When working with production systems, clever solutions are not always the best solutions.

Jaafar learned this through experience.

One early fix involved copying a core function, changing one line, and shipping it.

It worked.

Then the underlying platform changed that function three times across three releases.

His copy quietly diverged from the original implementation.

Eventually, the bug that returned looked nothing like the problem he had originally fixed.

The better solution was to use a documented filter and replace only the transport.

No fork.

No duplicated implementation.

No code that needed to be kept in sync with the platform.

When the platform gives you a seam, take the seam. Never fork.

The broader lesson is simple:

Prefer the boring integration point that the platform promises to keep working over the clever one that happens to work today.

Advice for Developers

When asked what habit developers should develop to become better at building reliable systems, Jaafar offered a surprisingly simple answer.

Before you accept that a check found nothing, point it at something you know is there.

The idea is straightforward.

If you are checking whether a value appears in a file, first test the check against a file where you know the value exists.

If you are verifying that a record is absent, first query a record you know exists.

The goal is to establish that the check itself is capable of finding what it is supposed to find.

Because sometimes the most dangerous result isn't an error.

It is a perfectly clean "nothing found."

Final Thoughts

Jaafar's journey is a good example of how real engineering experience is often built in places that tutorials don't cover.

It is built in production systems.

In traffic spikes.

In unexpected platform behaviour.

In multilingual content.

In failed background jobs.

In analytics numbers that answer the wrong question.

And especially in the quiet failures that look like success.

His approach is ultimately less about making systems look impressive and more about making them honest.

A system should tell you when it doesn't know.

A check should prove that it can actually see what it claims to see.

And when a platform provides a supported way to extend it, use that instead of building something that will quietly drift away from the original system.

For developers working with real users and real production systems, those lessons can be worth far more than another tutorial.

About Developer Stories

Developer Stories is a CoderLegion series featuring developers from our community and exploring the real journeys behind the code—the challenges they have faced, lessons they have learned, projects they are building, and experiences that can help other developers grow.

If you have a developer journey, engineering lesson, project, or experience you'd like to share with the CoderLegion community, we'd love to hear from you.