Coder Legion - Recent posts tagged fullstack

Modern Web Development in the Era of AI Agents

Wed, 14 Oct 2026 14:59:05 +0000

Beyond the Prompt: Modern Web Development in the Era of AI Agents

If you have spent any time scrolling through developer feeds lately, you’ve probably noticed a shifting sentiment. With LLMs generating scaffolding, debugging code inline, and AI agents spinning up full-stack MVPs in seconds, it is easy to wonder: What is the actual role of a web developer today?

Are we just professional prompters now, or is there a deeper craft to building for the web?

Let’s dive into how web development is evolving, what actually matters in the current ecosystem, and how modern engineers continue to ship robust, scalable applications.

1. The Shift from Boilerplate to Architecture

Not long ago, a massive chunk of a web developer's day was spent writing boilerplate code—setting up routing, configuring webpack, wiring up form validation, and managing basic CSS layouts.

Today, AI handles the syntax layer astonishingly well. But syntax is not architecture.

The modern web developer spends less time typing syntax and more time acting as a systems architect. Key responsibilities have shifted toward:

Data Flow & State Management: Deciding how data moves across server components, edge workers, and client stores.
Security & Auth Boundaries: Ensuring that AI-generated endpoints don't accidentally leak data or introduce insecure direct object references (IDOR).
Performance Budgets: Optimizing Core Web Vitals, managing bundle sizes, and reducing layout shifts in complex reactive applications.

2. The Tech Stack Dilemma: Keep It Lean

With frameworks and tooling evolving at breakneck speed, tech fatigue is real. Every week brings a new build tool, styling paradigm, or state library. However, elite teams are moving toward intentional minimalism.

The Return of the Server: Frameworks like Next.js, Remix, and SvelteKit have blurred the lines between frontend and backend. Server-Driven UI and React Server Components (RSCs) mean less JavaScript is shipped to the browser, leading to lightning-fast load times.
Utility-First Styling: Tailwind CSS remains a staple for rapid UI iteration, enabling developers to build responsive, accessible design systems without context-switching between stylesheets.
Edge Computing: Deploying logic closer to the user via edge functions (Vercel, Cloudflare Workers) has made global latency nearly negligible.

3. The Human Element: Why Craft Still Matters

When anyone can prompt an AI to build a generic landing page, quality and polish are your competitive advantages.

AI can write a React component, but it doesn't intuitively feel the micro-interactions, understand your user's specific emotional journey, or design an intuitive edge-case fallback when a network request fails.

Great web development requires:

Empathy for the User: Building accessible (a11y) interfaces that work for screen readers, low-bandwidth connections, and diverse devices.
Debugging Complex Logic: AI is great at writing code, but when a deeply nested race condition occurs across an asynchronous microfrontend architecture, you need a human engineer who can trace the stack trace and reason through the system state.

Summary: Building in 2026 and Beyond

Web development isn't dying; it’s graduating. By offloading mechanical coding tasks to AI tools, we are liberated to focus on what matters most: solving real user problems, building secure systems, and crafting delightful digital experiences.

What's your take? How has your workflow changed over the past year? Are you leaning entirely into AI-driven coding agents, or are you doubling down on foundational engineering principles? Drop a comment below and let's discuss!

How to Migrate WordPress to a Static Site Builder (Step-by-Step)

Thu, 08 Oct 2026 23:46:07 +0000

Moving a WordPress website to a static site builder can reduce dependence on traditional WordPress hosting, plugins, themes, and server-side maintenance. It can also provide a simpler visual workflow for building and maintaining pages.

But migrating a WordPress website is not the same as copying files from one server to another. WordPress stores content in a database and relies on themes, plugins, media files, and other components to produce the finished website. A visual site builder uses a different content and design system, so a successful migration requires planning, content export, rebuilding, testing, and careful handling of URLs.

Platforms such as Webflow and Framer provide current migration workflows for WordPress sites. Webflow's official documentation describes the process as a rebuild rather than an automated transfer, while Framer provides a dedicated WordPress migration guide covering content, media, plugins, SEO, and CMS collections.

Here is a practical step-by-step process for moving a WordPress website to a static-oriented site builder.

Audit the Existing WordPress Website
Do not start rebuilding the website immediately.

First, create an inventory of what currently exists.

Review your WordPress pages, posts, categories, tags, custom post types, media files, forms, integrations, plugins, and important URLs. The purpose is to determine what actually needs to move and what can be removed.

WordPress's export system can include posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, and users in its XML export.

Your audit should answer several basic questions:

Which pages are essential?
Which blog posts need to be migrated?
Which URLs receive significant traffic?
Which images and downloadable files are still required?
Which WordPress plugins provide functions that must be replaced?
Which content belongs in a CMS collection?
Which pages can become ordinary static pages?
Are there outdated posts or pages that should be removed instead of migrated?
Does the existing site use custom post types?
Are there forms, newsletters, search functions, memberships, or ecommerce features that require replacement?
Framer's current WordPress migration documentation similarly recommends cataloging pages, posts, custom post types, media, and plugins before migration.

This audit prevents a common migration mistake: rebuilding every part of an old website without questioning whether those parts are still necessary.

Choose the Destination Builder
The next decision is where the rebuilt website will live.

Webflow and Framer are two examples of visual platforms with current WordPress migration documentation.

Webflow provides a CMS that uses Collections to manage structured dynamic content. It supports CSV import for CMS Collection items, which makes structured content migration possible after converting WordPress's XML export into a compatible CSV file.

Framer also provides a CMS and documents several approaches for moving WordPress content, including CSV-based migration for larger amounts of structured content. Its documentation specifically describes mapping WordPress custom post types and ACF-managed content to CMS collections.

The correct platform depends on the website rather than the migration tool alone.

A simple marketing website with a few pages may require very little CMS structure. A publication with hundreds or thousands of articles requires a more deliberate content architecture.

Before committing to the destination, check its current CMS limits, import capabilities, hosting requirements, forms, integrations, SEO controls, and domain configuration.

Back Up the WordPress Website
Create a complete backup before making major migration changes.

WordPress recommends maintaining backups of both the database and the site's files. The database contains content such as posts, comments, and links, while the site's files contain WordPress core files, plugins, themes, images, and other website assets.

Do not treat the WordPress XML export as a complete website backup.

The WordPress export file is useful for moving content, but the official WP-CLI documentation notes that WXR exports do not include site configuration or the attachment files themselves.

A proper backup gives you a recovery point if something goes wrong during the migration.

Keep the original WordPress website available until the new website has been completely tested and launched.

Export Your WordPress Content
WordPress provides a built-in export function under the administration area.

Go to:

WordPress Dashboard → Tools → Export

From there, select the content you want to export and download the generated XML file.

WordPress calls this format WordPress eXtended RSS, or WXR. The export can contain posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, and users, depending on the selected content.

For a migration, you may need separate exports or additional processing depending on the content structure and destination platform.

Do not assume that exporting XML automatically creates a finished version of your new website. The XML is a content source. The destination builder still needs to receive that content in a structure it can understand.

Webflow's current WordPress migration documentation specifically states that WordPress content is exported as XML and that the XML can be converted to CSV before importing it into Webflow.

Convert and Clean the Content
This is one of the most important stages of the migration.

A WordPress site may contain content that depends on WordPress-specific formatting, shortcodes, plugins, custom fields, or theme functionality.

Do not simply move the text and assume the formatting will remain identical.

Review the exported content for:

Shortcodes
Broken HTML
Unnecessary formatting
Old internal links
Missing images
Unused metadata
Outdated categories
Duplicate content
Plugin-specific elements
Embedded content that depends on WordPress
Custom fields that need new CMS fields
If you are migrating to Webflow, its current documentation recommends converting the WordPress XML export into CSV before importing the content into a CMS Collection. Webflow's CMS importer then allows fields from the CSV to be mapped to existing or newly created Collection fields.

Framer's migration documentation also identifies CSV import as a common approach for bulk WordPress content and recommends cleaning WordPress-specific formatting during the conversion process.

This stage is an opportunity to improve the content database rather than reproduce unnecessary legacy structures.

Rebuild the Content Structure
Once the content is clean, determine how it should be organized in the new platform.

A WordPress blog might have posts, authors, categories, tags, featured images, excerpts, and custom fields. Your new builder may organize these differently.

For example, a blog could use a CMS collection containing fields such as:

Title
Slug
Author
Publication date
Featured image
Excerpt
Main content
Category
Tags
SEO title
Meta description
The exact fields should match the requirements of the website.

Webflow describes a CMS Collection as a structured database for a particular type of content. Its CMS allows dynamic content to be managed from a shared structure rather than manually maintaining repeated information across pages.

This distinction matters because not every WordPress page should become a CMS item.

A homepage, contact page, about page, and pricing page may be better treated as individual static pages. Blog posts, case studies, team members, products, or testimonials may be better managed through collections.

Import the Content
After creating the destination CMS structure, import the prepared content.

In Webflow, the current workflow is to create a Collection, open its import function, upload the CSV, confirm the header row, map the columns to Collection fields, review the imported items, and complete the import. Webflow also provides error reporting when imported records fail.

Large migrations should be handled in controlled batches rather than treated as one giant operation.

Import a manageable group first.

Then check:

Titles
Slugs
Text formatting
Images
Categories
Dates
Author information
Internal links
Custom fields
If the first batch works correctly, continue with the remaining content.

This approach makes it easier to identify structural problems before they affect the entire migration.

Rebuild the Website Design
Content migration does not automatically reproduce the old WordPress theme.

The new website needs to be rebuilt using the destination platform's design system.

Start with the site's core structure:

Header
Navigation
Homepage
Main content templates
Blog or article template
Footer
Contact page
Other important landing pages
Then reproduce the visual elements that are actually required.

This is another reason to audit the WordPress website before beginning. A migration is a good time to remove obsolete design components instead of rebuilding them simply because they existed in the old theme.

Webflow explicitly describes WordPress migration as a rebuild in which page layouts, styles, CMS structures, and interactions are recreated in Webflow.

Framer's migration documentation similarly separates content migration from the work of rebuilding the site's design and functionality.

Replace WordPress Plugin Functionality
Plugins require special attention.

A WordPress plugin may provide forms, SEO functions, analytics integration, caching, redirects, ecommerce capabilities, social integrations, or other features.

Those functions do not automatically transfer to the new platform.

Create a plugin inventory and classify every plugin into one of three categories:

Replace: The function is still required but must be implemented through another service or native feature.

Rebuild: The function is important and must be recreated within the new platform.

Remove: The function is no longer necessary.

This prevents a common migration problem where the new website looks correct but loses important functionality.

For example, if a WordPress contact form was responsible for receiving customer inquiries, the new website must have another verified method for receiving those submissions before the old website is retired.

Preserve Your URL Structure
URL management is one of the most important parts of a migration.

WordPress describes permalinks as the permanent URLs used for posts, pages, categories, tags, and other archive pages.

Whenever practical, preserve existing URLs.

If a URL must change, create a permanent redirect from the old address to the correct new address.

For example:

Old URL:
example.com/blog/website-speed-guide/

New URL:
example.com/website-speed-guide/

The old URL should redirect to the new URL rather than simply returning an error.

Webflow's migration documentation specifically includes 301 redirects and SEO considerations as part of its WordPress migration process.

Framer's WordPress migration guidance also identifies URL mapping and permanent redirects as important parts of an SEO migration.

Create a spreadsheet containing the old URL, new URL, and redirect destination before launch. This gives you a clear record of every URL change.

Recreate SEO Metadata
Moving the visible content is not enough.

Review the SEO information associated with important pages and posts.

Check:

Page titles
Meta descriptions
Slugs
Heading structure
Canonical settings where applicable
Image alt text
Internal links
XML sitemap
Robots directives
Redirects
Do not automatically assume that the new platform will reproduce your WordPress SEO configuration.

Some SEO settings may have been controlled by a WordPress plugin rather than WordPress itself. Those settings must be recreated using the capabilities of the destination platform.

The goal is to make the new website understandable to both visitors and search engines while preserving important existing URLs.

Test the New Website Before Launch
Never switch the domain immediately after finishing the build.

Test the new site first.

Open important pages manually and inspect them on desktop and mobile devices.

Test:

Navigation
Buttons
Forms
Images
Videos
Internal links
External links
Search functionality
CMS templates
Contact processes
Redirects
Page titles
Meta descriptions
404 behavior
Downloadable files
Pay particular attention to migrated articles.

Open old high-value URLs and confirm that they either remain available at the same address or redirect correctly to the new location.

Also test pages that were imported in bulk. A migration can succeed technically while individual records still contain missing images, broken formatting, or incorrect links.

Webflow's current migration checklist recommends importing CMS content, designing pages and templates, and carrying out the migration in stages rather than treating content transfer as the entire process.

Connect the Domain and Launch
Once testing is complete, configure the new platform for the production domain.

The exact domain process varies between site builders, so follow the current documentation for the platform you selected.

Do not shut down the WordPress site before confirming that the new website is working on the production domain.

Once the new site is live, test the most important URLs again.

Check the homepage, major landing pages, high-traffic articles, contact forms, redirects, and other business-critical functions.

Keep the WordPress backup even after launch.

Monitor the Website After Migration
The migration is not finished simply because the new site is live.

Monitor the website after launch for broken links, missing pages, redirect problems, indexing issues, form failures, and missing assets.

Compare the new website against your original migration inventory.

If a page or feature was supposed to be transferred but cannot be found, investigate it immediately.

It is also useful to keep the old URL-to-new URL mapping available after launch. If visitors or search engines encounter an old URL, the mapping tells you where that URL should lead.

Common WordPress Migration Mistakes to Avoid
Several mistakes repeatedly create unnecessary problems during website migrations.

Migrating without a backup
A WordPress XML export is not a complete backup of the entire site. Keep a separate backup of the database and files.

Assuming the migration is automatic
Webflow explicitly states that moving a WordPress site to Webflow requires rebuilding the site.

Moving content without cleaning it
Shortcodes, obsolete formatting, broken links, and plugin-dependent elements can survive the export process and cause problems in the new system.

Ignoring URLs
Changing URLs without implementing appropriate redirects can create broken links and unnecessary SEO problems.

Forgetting plugin functionality
A WordPress plugin may perform a critical task that is not visible on the front end. Inventory your plugins before migration.

Launching without testing
A website that looks correct on the homepage can still contain broken forms, missing images, incorrect links, or failed redirects elsewhere.

Migrating WordPress to a static-oriented site builder is best treated as a website reconstruction project, not a simple file transfer.

The safest process is straightforward: audit the existing website, back up the WordPress installation, export the content, clean and restructure the data, import it into the new CMS, rebuild the design, replace essential plugin functionality, preserve URLs, configure redirects, reproduce important SEO information, test everything, and only then launch.

Webflow and Framer both provide current documentation specifically addressing WordPress migrations, but their workflows demonstrate an important point: the destination platform needs to be planned around the site's actual content and functionality.

A smaller WordPress site may require only a modest amount of rebuilding. A large content-driven website can require substantial preparation because every page, CMS record, image, URL, plugin function, and integration needs to be accounted for.

The objective should not be to reproduce every technical detail of the old WordPress installation. The objective is to preserve the content and functionality that matter, establish an appropriate structure in the new platform, protect existing URLs where possible, and launch a website that can be maintained without carrying unnecessary WordPress complexity into the new system.

From Software Development to AI & Real Estate Tech — Waqas Ahmad’s Developer Journey

Thu, 08 Oct 2026 12:57:44 +0000

From Software Development to AI & Real Estate Tech — Waqas Ahmad’s Developer Journey

“Coding may help you build the product, but understanding people helps you build something people actually want to use.”

Waqas Ahmad's journey into technology didn't begin with a computer.

It began with his family.

Growing up, he watched his father work hard to build a better future for the family. His father had come from a rural area near Burewala, supported his own education by teaching, and later spent years serving patients despite limited medical facilities.

That example shaped Waqas's attitude toward education, hard work and persistence.

Initially, Waqas wanted to become a doctor.

He chose the medical stream during matric, but his father encouraged him to consider technology, believing computers would become increasingly important.

Waqas changed direction.

He studied ICS and eventually enrolled in a BS Computer Science program at Virtual University of Pakistan.

But his path into software development wasn't straightforward.

While studying, he also had family responsibilities and worked different local jobs, including as a helper, cashier and later handling accounts and store responsibilities at a restaurant.

He continued studying alongside those responsibilities.

Eventually, a school friend, Saulat Abbas, helped strengthen his programming skills and encouraged him to keep coding.

Waqas started small.

Calculators.

Simple JavaScript games.

Small projects.

Then those experiments gradually became something more serious.

He joined Pixel Perfects while still completing his degree and began working on real software projects.

That was when technology stopped being only something he was studying.

It became something he was building.

From Learning to Building Real Products

Early in his development journey, Waqas was particularly interested in frontend development and UI/UX.

He enjoyed thinking about how an interface should look, how users should move through it and how a product could become easier to understand.

But working on real projects taught him that building software is only part of the equation.

A product also needs users.

Someone needs to understand those users.

Someone needs to communicate with clients.

Someone needs to explain what the product does.

Someone needs to market it.

And someone needs to make sure people can actually find it.

That realization gradually expanded Waqas's role beyond pure development.

His experience at Pixel Perfects exposed him to both sides.

He worked on frontend and full-stack projects before moving into customer support and client communication.

He discussed requirements with clients, handled orders and revisions, coordinated with developers and designers, and helped ensure projects were delivered according to expectations.

Later, when EstateAI launched, his responsibilities expanded further into SEO, content marketing, product listings, directory submissions, blogs and social media.

His technical background became an advantage.

He wasn't simply marketing a technology product.

He understood the technology behind it.

Why Frontend Remained Important

Although Waqas has worked across the stack, frontend and product experience remain the areas he enjoys most.

He particularly enjoys taking an idea and turning it into an interface that people can actually use.

Early in his development journey, he noticed that some of his friends were stronger in programming logic while he had a stronger eye for interfaces and user experience.

Instead of treating that difference as a weakness, they worked together.

He learned from them.

They learned from him.

Over time, Waqas became more comfortable working across the stack.

His experience includes technologies such as:

React.js
Next.js
Node.js
Express.js
MongoDB
MySQL
Firebase
REST APIs
Tailwind CSS
Bootstrap
Git & GitHub

But technical breadth isn't the only lesson he took from full-stack development.

He learned that a feature can technically work and still have a problem.

If users find it confusing or difficult to use, the product still needs improvement.

That perspective has remained with him even as his career expanded into customer-facing and content roles.

He naturally thinks about both sides:

How does it work technically?

How does it feel to the person using it?

When Development Meets Content

Waqas's move into content creation wasn't a complete departure from software development.

It was an extension of it.

He discovered that technical products need communication.

A product can be well engineered and still fail to reach people if nobody understands what it does or why it matters.

His work in content and SEO gave him a different perspective on technology.

He began creating blogs, articles and social media content.

He worked on SEO and backlink building.

He listed products on relevant platforms.

He helped with directory submissions and online visibility.

He also continued communicating directly with customers.

That combination taught him something important:

Good software needs good communication.

And good technical content requires an understanding of the technology behind it.

For Waqas, development and content are therefore not completely separate disciplines.

They solve different parts of the same problem.

EstateAI: Applying AI to Real Estate

One of the most important products in Waqas's current journey is EstateAI.

The idea comes from a practical problem in real estate marketing.

Property professionals often need to prepare and improve large numbers of property images before they can effectively market a listing.

That can involve repetitive tasks such as:

Improving images
Staging empty rooms
Changing the atmosphere of a photo
Removing unwanted objects
Visualizing different possibilities for a property

EstateAI approaches this as an AI-powered property marketing workspace.

The goal isn't simply to generate an impressive image.

It's to make AI useful inside an actual property marketing workflow.

That distinction matters.

A real estate professional needs more than an attractive AI-generated image.

The property still needs to look like the same property.

Its architecture matters.

The room layout matters.

The camera perspective matters.

The overall identity of the space matters.

AI becomes useful when it improves the presentation without losing those important characteristics.

Making AI Useful Instead of Just Impressive

One of the biggest challenges Waqas sees in AI-powered real estate technology is balancing visual quality with accuracy.

People may see impressive AI-generated images and assume every result will automatically be perfect.

Professional workflows are different.

Reliability and consistency matter just as much as visual quality.

There is another challenge too:

The user shouldn't need to understand the technology.

A realtor shouldn't have to understand AI models, prompting techniques or complicated settings just to improve a property photo.

That leads to one of Waqas's central product principles:

The value of AI isn't only in the underlying technology. It's in turning that technology into a workflow that solves a specific problem without creating unnecessary complexity for the user.

Start With the User, Not the Technology

Waqas's experience in customer support has strongly influenced how he approaches product development.

When you communicate directly with customers, you hear things developers don't always hear.

Where people get confused.

What they expected.

What frustrates them.

Which features they actually care about.

That experience changed how Waqas thinks about software.

Instead of starting with:

“What can this technology do?”

He prefers to start with:

“What problem are we solving?”

And then:

“Does this actually make the user's work easier?”

This is particularly important with AI.

AI makes it possible to build an enormous number of technically impressive features.

But technically impressive doesn't automatically mean useful.

Good product development means being honest about what the technology can actually do while designing the experience around what users genuinely need.

CodersWire and the Reality of Product Development

Another important project in Waqas's journey was CodersWire.

Unlike an academic exercise, it gave him an opportunity to work on a real-world product.

His contribution was mainly focused on the frontend and UI/UX side, working with technologies including Next.js, TypeScript, MUI, Tailwind CSS, Google Maps and React Slick.

The project also involved backend technologies including NestJS, MySQL, TypeORM, AWS and Nodemailer.

The experience reinforced a lesson that goes beyond any individual technology:

Building software is very different from completing a coding task.

A real product requires thinking about the complete system.

How components communicate.

How users interact with the interface.

How the application evolves.

How different people contribute.

How the product responds to changing requirements.

It also reinforced the importance of collaboration.

Waqas had friends and colleagues who were stronger in areas where he was still developing, particularly programming logic and backend concepts.

Working with them helped him improve faster than trying to learn everything alone.

What Customer Support Taught Him About UX

Working directly with customers changed Waqas's thinking about software more than he expected.

As a developer, it can be easy to focus on whether a feature technically works.

Customer conversations reveal another reality.

A technically correct product can still be difficult to use.

Or difficult to understand.

Or simply different from what the customer expected.

In his customer-facing role, Waqas dealt with:

Project discussions
Client requirements
Orders
Coordination
Deliveries
Revisions
Communication between customers, designers and developers

That experience taught him to look beyond what customers literally say and try to understand what they actually need.

He now carries that perspective into both product development and content creation.

When he explains or promotes a product, he tries to think about the questions a real user would ask rather than simply listing technical features.

Turning Complex Technology Into Simple Ideas

Waqas's approach to technical content starts with the audience.

A developer might immediately understand terms such as:

APIs
AI models
Server-side rendering
Automation

But a business owner or general user may not need to understand all of those technical details.

So Waqas asks three questions:

What does this technology do?

Why does it matter?

How can it help the person reading it?

From there, he prefers simple language, practical examples and real use cases.

His development background helps him understand the technical side.

His customer-facing experience helps him communicate that technical side.

For him, good technical content shouldn't make readers feel like they need a technical background just to understand the idea.

It should leave them with a clear understanding of what the technology means and why it matters.

AI and the Role of Human Judgment

Waqas sees AI as one of the most useful tools available to modern developers and content creators.

It can reduce repetitive work.

It can help explore solutions.

It can generate initial code.

It can help with debugging ideas.

It can support learning unfamiliar concepts.

In content and marketing, AI can assist with research, brainstorming, drafting and organizing information.

But Waqas doesn't see AI as a replacement for human judgment.

In fact, he believes AI can make human judgment more important.

Someone still needs to decide:

Is the output accurate?
Does it actually solve the problem?
Is the message appropriate for the audience?
Does the result feel authentic?
Is the idea worth pursuing?

AI can generate possibilities.

Humans still need to decide which possibilities are worth pursuing.

The Challenge of Building While Life Keeps Moving

One of the biggest challenges in Waqas's journey wasn't purely technical.

It was building a career while managing responsibilities outside his studies.

There were periods when he worked long hours in local jobs while continuing his education.

He also had family responsibilities.

That made his path slower and more difficult than simply focusing entirely on university and coding.

There was another challenge too.

He recognized that he wasn't equally strong in every part of development.

UI/UX and frontend came naturally to him.

Programming logic required more practice.

Instead of treating that difference as a reason to stop, he learned from people around him.

Saulat Abbas helped strengthen his coding foundation.

Working with Abdullah Sheikh taught him the value of collaboration, particularly because Abdullah was strong with JavaScript logic.

That experience taught Waqas something important:

Progress doesn't always mean being the best person in the room.

Sometimes it means finding people you can learn from.

Don't Limit Yourself to Coding

For Waqas, one of the biggest lessons from his career is that developers shouldn't limit themselves to coding.

Technical skills are important.

But building a product requires much more.

It requires understanding:

Users
Communication
Marketing
Customer support
Business problems
Product positioning
User experience

His own career demonstrates that.

He has moved between:

Development.

Customer support.

Content.

SEO.

Product marketing.

Each role gave him a different perspective on how software actually reaches people and serves customers.

That combination has become one of his strengths.

Start Small and Build for Real

For developers who want to build their own products, Waqas recommends starting before they feel completely ready.

Talk to users early.

Understand the problem before deciding what technology to build.

Learn enough about marketing and communication to explain the product clearly.

And don't wait until you know everything.

A first project doesn't need to be impressive.

It could be:

A calculator.

A simple game.

A small web application.

What matters is actually building it.

Those early projects teach concepts that tutorials alone can't provide.

They also create the confidence needed to tackle larger problems later.

Don't Compare Your Timeline

Waqas's own journey is a good example of why comparing development timelines can be misleading.

His path wasn't straightforward.

He changed direction from medicine to computer science.

He worked local jobs while studying.

He developed his programming skills gradually.

He moved between development, customer support, content, SEO and product marketing.

He became involved with AI and real-estate technology.

None of it happened through a perfectly planned route.

And that's okay.

His advice is not to compare your timeline with someone else's.

Technology changes constantly.

The important skills are not limited to a particular framework or programming language.

The ability to learn.

The ability to adapt.

The ability to communicate.

And the willingness to keep improving.

Those skills continue to matter even when the technology changes.

Looking Ahead: AI, SaaS and Real Estate

Waqas's current interests sit at the intersection of three areas:

AI.

SaaS.

Real estate technology.

His experience with EstateAI has shown him how much opportunity exists in industries that still contain manual and repetitive workflows.

He wants to continue exploring AI-powered products that solve practical business problems rather than simply adding AI because it is popular.

At the same time, he wants to continue improving his development skills while remaining involved in content, SEO and product marketing.

That combination suits the way he naturally thinks about technology.

He enjoys being involved at different stages of a product:

From understanding the technology.

To thinking about the user.

To communicating the product's value.

To helping people discover it.

Long term, he wants to contribute to products where technology, business and user experience come together in a meaningful way.

From Doctor to Developer

Looking back, Waqas's journey could have gone in a completely different direction.

He initially wanted to become a doctor.

His father encouraged him to consider technology.

He changed direction.

He studied computer science.

He worked local jobs while studying.

He learned from friends.

He built small projects.

He entered professional software development.

Then his career expanded beyond development into customer support, content, SEO and product marketing.

Today, he's working around AI and real-estate technology while continuing to develop his technical skills.

The journey wasn't linear.

But every stage contributed something.

His father's example taught him persistence.

Working while studying taught him resilience.

Friends taught him collaboration.

Development taught him how to build.

Customer support taught him how users think.

Content and SEO taught him how to communicate value.

And AI is giving him new ways to connect technology with real-world problems.

Building at the Intersection

Waqas's story isn't simply about becoming a better programmer.

It's about discovering that technology products live at the intersection of many disciplines.

Code matters.

But so does design.

So does communication.

So does marketing.

So does customer understanding.

And increasingly, so does AI.

His journey has taken him across all of those areas.

And that may ultimately become his biggest advantage.

Because building a useful product isn't just about asking:

“Can we build it?”

It's also about asking:

“Should we build it?”

“Who needs it?”

“Will they understand it?”

“Will they actually use it?”

And:

“Does it solve a real problem?”

For Waqas Ahmad, those questions are becoming just as important as the code itself.

About Waqas Ahmad

Waqas Ahmad is a Software Engineer and Content Creator working across software development, AI, digital marketing and real-estate technology.

His technical background includes JavaScript, TypeScript, React.js, Next.js, Node.js, Express.js, MongoDB, MySQL, Firebase, REST APIs, Tailwind CSS, Bootstrap and Git/GitHub.

He has worked on full-stack applications, developer platforms and AI-powered real-estate products, while also building experience in customer support, SEO, content marketing and product communication.

View Waqas's profile on CoderLegion

Visit Waqas's website

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

Hi, I'm Arham Sayyed: full-stack dev, occasional security researcher, full-time curious person

Tue, 29 Sep 2026 20:14:39 +0000

The short version

I'm Arham Sayyed. I build full-stack apps for a living, break things for fun (and sometimes for money), and teach undergrads how to do both, badly at first, better eventually.

Stack of choice: MERN, Next.js, React Native, TypeScript. If it's not in that list, I've probably still touched it, just less happily.

How I actually got here

I didn't start out planning to split my time between "ship this for a client by Friday" and "why does this SIEM alert look wrong." It happened in the normal messy way: one freelance project led to another, one curiosity about why an app was insecure turned into actually building security tooling, and one guest lecture turned into an ongoing teaching gig I didn't see coming.

Most of my paid work has been freelance and contract: restaurant tech, internal tools, automation that saves someone three hours a week they'll never think about again. The unglamorous stuff, mostly. I like it because the constraints are real: real users, real deadlines, real "wait, why is this endpoint public" moments at 11pm.

The security rabbit hole

The instinct that makes me decent at building software is the same one that makes me decent at breaking it: I don't like taking "it works" at face value. That curiosity eventually turned into contributing to Haxnation's platform engineering. I worked on the backend behind their SOC simulation platform, which maps realistic SIEM alerts and analyst triage workflows to the MITRE ATT&CK framework so people can practice incident response against scenarios that actually resemble the real thing, not a sanitized textbook version.

Alongside that, I've been building out a threat-intel aggregation tool for myself (RSS/Atom feeds, dedup, a terminal UI because I have a weakness for TUIs), and I spend a fair amount of time at Mumbai's cybersecurity meetups and CTFs, mostly listening to people smarter than me talk about things breaking in new ways.

The teaching side

I lecture Programming Languages and Web Technologies to students at a college in Mumbai. I did not expect this to become a real part of my career, and yet, here we are.

What surprised me most is how much it sharpens my own understanding. You can hold a fuzzy mental model of something and still ship working code with it. You cannot stand in front of 40 students and explain that fuzzy model without someone asking the one question that reveals you never actually understood it. Teaching has made me a better engineer more directly than almost any project has.

Things I've built that I'm reasonably proud of

A SOC simulation backend (Haxnation): JWT auth, MITRE ATT&CK-mapped alert scenarios, JSON-driven so new attack scenarios don't need a database migration.
A job-outreach automation tool, open-sourced, that does company discovery, contact extraction, and LLM-personalized outreach with a human still in the loop, because fully autonomous cold outreach is how you get your domain blacklisted.
A QR-code digital menu platform for restaurants: unglamorous, genuinely useful, still running.
A handful of open source contributions: a merged fix in Pyrebase4, a 440+ line documentation pass on Multer's internals, and a small API migration when a free-tier shutdown nearly killed a public quotes API.
mms-forced-align: a Node.js/TypeScript port of CTC forced alignment on top of Meta's MMS acoustic model. Give it audio plus a transcript you already know was spoken, get back the start/end timestamp of every word. As far as I can tell, no published JS implementation of MMS-based forced alignment existed before this; the closest tools were Python-only. It also does something I haven't seen elsewhere in JS: romanizing 20 Indic languages internally so you can align native-script transcripts (Hindi, Tamil, Urdu, Bengali, and so on) and get timings mapped back onto the original script. Verified against torchaudio's pipeline down to sub-millisecond accuracy, and, mildly satisfying, faster than it in CPU benchmarks too.

Also, this one's actually shipped

Most of what's above is backend work nobody outside the project sees. This one's different: Read Me When is a React Native app, live on Google Play, built as a product of Build Incredibles.

The idea is simple: some feelings are too big for words, so instead of searching, you just pick how you're feeling: happy, anxious, thankful, lonely, angry, sad. The app draws a Quranic verse matched to that feeling. Tap in and you get the Arabic text, transliteration, full translation, recitation audio, and classical tafsir, so you're not just reading words out of context. Save what speaks to you, share it as a designed card, browse by feeling later. No account, no ads. Everything lives locally on the device.

It's the one project on this list where the "does it actually work under real use" question isn't about uptime or load, it's about whether it's actually useful to someone at 2am when they open the app because they don't have the words for what they're feeling. That's a much harder bar than anything else here.

the interesting part was never the recognition, it was the "how do I make this messy, half-formed idea actually work under real load" problem in the middle.

What I'll probably write about here

Mostly: things I build, things that broke while I was building them, and whatever I've been thinking about at the intersection of web dev and security. Sometimes teaching stories, if they generalize past "why did nobody submit the assignment on time."

If you're building something similar, breaking something similar, or teaching something similar, say hi. I'm at arhamsayyed.dev@gmail.com, or @arhamsayyed_dev on X.

My Socials

Instagram
X / Twitter
Medium
LinkedIn
GitHub

You can also checkout Build Incredibles

I was hoping for conversation

Sun, 23 Aug 2026 16:53:14 +0000

When I started actually experimenting with transpiling my own ideas into the languages that the browser understands. I really didn't have any idea where I was going to end up. I certanily didn't expect to flip the whole damn paradigm; but hey, the only way out is through, right?

Don't hate me, but, I love JavaScript. It's easy, fast to prototype, and runs absolutely everywhere (as long as "everywhere" is in a browser ;)

HOWEVER!!! JavaScript's way of interfacing with its native sibling langs, is fucking atrocious! In 30 years, the coolest component I ever built; might have been the most hideous code ever written.

And it's completely understandable. Tell someone to build a programming language in 11 days. Not a GD one of us would do any better.

So, obviously the most popular language in the world, has some room for improvement.

I believe that, to some extent, I have done just that. But that is only MY opinion. Which is worth about as much as it weighs.

What is worth FAR more, is the convergence of ideas. The give and take, the controversy and cooperation. In short, conversation.

I am devoid of the hubris required to say: "I know better then all of you."

But, if this path is worth walking. And I believe that it is. Then with some descent to what I might have gotten wrong. Some options I didn't see. etc. scrml could be something special.

I may be wrong. I accept that possibility gladly. But how will I ever know, without conversation?

Choosing the Right Technology Stack for Startup MVP Development

Mon, 20 Jul 2026 13:17:31 +0000

Quick Overview

MVP stack decisions affect burn rate, iteration speed, and how easily
a product can pivot after early user feedback
Frontend framework choice trades short-term development speed against
long-term maintainability and hiring pool depth
Backend and database decisions determine how much technical debt
accumulates before a funding round
Managed hosting and serverless infrastructure remove operational
overhead most early teams can't afford to staff
The right stack matches the team's existing skills to the actual
complexity the product needs to solve today

Most stack mistakes come from over-engineering for scale the product hasn't earned yet
A founder sits down with two developers and six months of runway. Within the first week, they've already made the decision that will shape whether that runway stretches into a validated product or gets eaten by rewrites: what to build with. Choose a stack sized for a fifty-engineer company with a Series B budget, and half that runway disappears into infrastructure nobody asked for. Choose something so minimal it can't support the second version of the product, and the rebuild costs more than starting over would have. The stack is the first real constraint an MVP operates under, and it's usually chosen with the least information the company will ever have.

Why the Stack Decision Shapes Your Learning, Not Just Building

An MVP exists to answer a question, not to demonstrate engineering sophistication. Its job is to test whether a core hypothesis about the market holds, not to prove the product can survive a load it doesn't have yet. Every hour spent building infrastructure for traffic that doesn't exist is an hour not spent finding out whether anyone wants the product. This is why many startups turn to bespoke MVP development services that prioritize speed, validation, and practical execution over unnecessary technical complexity.

This is where early technical decisions often go wrong. A team reaches for a distributed architecture or a trending framework nobody on the team has actually shipped with. None of that reduces risk at the MVP stage. What reduces risk is picking tools the team already understands well enough to move fast and debug quickly before a demo.

Aligning a startup's tech stack with its business, team, and financing.

Every startup tech stack decision should start with two questions: what does the team already know, and how much runway exists to learn something new? A team of backend engineers with deep Node.js experience will ship faster on a JavaScript-heavy stack than on an unfamiliar framework, even one objectively better suited to the problem on paper. Familiarity compounds, and every unknown tool introduces debugging time unrelated to the actual product.

Partnering with bespoke MVP development services can shorten this discovery phase and boost web development efficiency early on, since teams that have already shipped multiple MVPs know which stack trade-offs matter and which are noise. Business model matters just as much: a content-heavy marketplace has different data and rendering needs than a real-time collaboration tool, and picking a stack before understanding that shape almost always means picking the wrong one.

Frontend Choices: Balancing Speed and Flexibility

React-based frameworks like Next.js remain a common MVP default because of their hiring pool, mature ecosystem, and built-in support for server-side rendering, which matters for pages that need to load fast and be indexed. Vue and Svelte offer a gentler learning curve, but the trade-off is a smaller hiring pool when contractors need to be brought in quickly.

The real mistake isn't React versus Vue. It's adding architectural complexity, like micro-frontends or a custom design system, before there's a product mature enough to need either.

Backend and Database Decisions That Shape Debt Accumulation

A monolithic backend is almost always the right call for an MVP, even though microservices dominate engineering discourse. A monolith is easier to reason about, deploy, and refactor when the product's shape changes after user feedback. Splitting services prematurely adds latency and coordination overhead that a small team can't absorb.
Database choice follows similar logic. PostgreSQL handles most early data models well, including ones that later need flexibility, since it supports JSON columns without a full migration to a document store. NoSQL earns its complexity when data is genuinely unstructured or write throughput at scale is a known near-term requirement, not a hypothetical one. REST covers almost every MVP's API needs; GraphQL earns its complexity only when the frontend genuinely needs flexible, nested data fetching across many client types.

Hosting, Infrastructure, and Managed Services Case

Platform-as-a-service providers like Vercel, Render, and Railway remove most of the operational burden that used to require a dedicated DevOps hire. For a team without in-house infrastructure expertise, that trade-off almost always favors managed hosting over a self-managed cloud setup, even though raw cloud offers more control.

That calculus flips once traffic and data volume grow, but that point is rarely reached during the MVP phase. What does matter early is a basic CI/CD pipeline from day one, so every deploy is tested and repeatable rather than a manual process someone has to remember correctly under pressure.

Common Founder Mistakes in Choosing an MVP Stack

The most frequent mistake is over-engineering for a scale the product hasn't earned. Building for a million users when the real question is whether the first hundred will come back wastes time and money on problems that may never materialize.

A close second is chasing a trending framework without checking whether the team has real depth in it. A stack that looks impressive on paper but that nobody can debug efficiently slows the product down exactly when speed matters most. Skipping basic observability, like error tracking and structured logging, is another common gap, since founders assume monitoring can wait, then end up debugging blind during the exact period when user trust is most fragile.

Conclusion

Getting the startup tech stack right at the MVP stage isn't about picking the most advanced tools available. It's about matching the team's actual skills, the product's real data and interaction patterns, and the available runway to a set of choices that are boring enough to be reliable and familiar enough to move fast on. The goal isn't architectural perfection. It's building something real enough to test a hypothesis before the money runs out, on a foundation that won't need to be torn down the moment the product finds traction.

Frequently Asked Questions

1. What is the best tech stack for an MVP?

There isn't a single best stack. The right choice depends on the team's existing skills, the product's data model, and available runway. A common, low-risk default is a monolithic backend, a relational database, and a mature frontend framework like React or Vue.

2. Should startups use no-code tools instead of custom development for an MVP?

No-code tools can validate simple ideas quickly, but they hit limits fast once the product needs custom logic or real scale. Many founders use no-code to test demand, then move to custom development once the concept is validated.

3. How much does it cost to build an MVP with a custom tech stack?

Cost varies widely by scope, team location, and complexity, so no universal figure applies. Scope creep is usually the bigger cost driver, since feature bloat adds development time regardless of the stack chosen.

4. Can I change my tech stack after launching an MVP?

Yes, and it's common. Many products rebuild parts of their stack once real usage reveals what the original architecture didn't anticipate. Choosing boring, well-documented tools at the MVP stage makes that migration easier.

5. Is it better to build an MVP with a monolith or microservices?

A monolith is almost always the better choice. It's simpler to build, deploy, and debug with a small team. Microservices add overhead that rarely pays off until the product has proven demand and a team large enough to own separate services.

Vibe Coding Isn't the Problem. Not Understanding the Stack Is.

Sat, 20 Jun 2026 14:22:11 +0000

I am not a developer by profession or practice. I'm a systems engineer with 20 years of experience. I have never been a developer or written any real code -- I barely wrote scripts -- but since AI came out I have come out of my comfort zone and started building again.

What I see in all the "vibe code everything" problems happening right now is that people are developing blindly. They don't understand the full stack. They see it as frontend and backend, when the full stack actually looks more like this (very partial list, just to make the point):

Source control
Frontend application layer
Backend application layer
API layer
Authentication and authorization
Database layer
Cache layer
File/object storage
Background jobs and messaging
Web server / reverse proxy
DNS

There are several other layers under that, and this is exactly why vibe coding fails -- people don't understand the stack. I have spent my entire career building the foundation and the stack that developers use, and sometimes destroy. So when I vibe code, it's different: AI is only writing the application code. I'm still building the entire stack underneath it.

The other piece is knowing all the parts well enough to ask questions and push back. When the AI makes a choice, I can ask why it chose that, or whether something else would be better. I also don't open a session with "build me X." I spend about 30 minutes talking through the process and the ideas first, then have Claude generate the best prompt for itself, and hand that over to Claude Code.

So to be clear: vibe coding is not a bad thing. It only becomes a problem when you don't understand the foundation and just want a single siloed change made with no idea what it touches.

What do you think?

Building Vylo — Looking for Collaborators, Partners & Early Support

Tue, 02 Jun 2026 13:30:26 +0000

https://auralenz.vercel.app

Hey developers
My name is Egimuk, and I’m building Vylo — a social platform focused on helping people connect, share, communicate, and build communities in a more modern and creative way.

This project started as an idea called Aura Lenz, but after refining the vision and direction, I renamed it to Vylo.
https://auralenz.vercel.app
The Link is not yet changed

What is Vylo?

Vylo is being designed as a modern social/community platform with features around:

Real-time chat and communication
Social feeds and posts
Communities and discussions
Media sharing
Modern UI/UX experience
Scalable architecture for future growth

The goal is not just to clone existing social apps, but to create something that feels fresh, lightweight, community-driven, and meaningful — especially for young people and growing digital communities.

Current Stack
Currently working with technologies like:

React + ShadcnUI + Vite
Node.js + Express.js
Socket.IO
MongoDB
TailwindCSS
Modern scalable frontend architecture

Why I’m Posting This

I’m looking for:

Collaborators

Developers, designers, product thinkers, or anyone passionate about building modern platforms.

Partners

People interested in helping shape the direction, growth, branding, marketing, or community side of the project.

Early Supporters / Investors
Individuals or organizations interested in supporting an ambitious African tech startup idea at an early stage.

Who I’d Love to Connect With:

Frontend developers
Backend developers
Mobile developers
UI/UX designers
Branding & marketing people
Startup mentors
Investors interested in African tech
Students who want to build something impactful

Why I Believe in This Project:

I come from Rwanda, and I strongly believe more globally scalable tech products can emerge from Africa.

Many young developers have ideas but lack:

collaboration opportunities
mentorship
funding
strong communities

I want Vylo to become more than just an app.
I want it to become a platform built with community energy from the beginning.

Current Stage

The project is still growing and evolving, but major foundations and ideas are already being developed.

Right now, I’m mainly focused on:

architecture
feature planning
UI/UX refinement
scalability
branding direction

Interested?

If you’re interested in collaborating, partnering, supporting, or simply exchanging ideas, feel free to comment or reach out.

You can even contact me on:

email: Emails are not allowed
instagram: https://instagram.com/__egimuk__ or https://instagram.com/__vylo_
auralenz(to be changed to Vylo): https://auralenz.vercel.app/profile/__egimuk__

I’d genuinely love to connect with people who enjoy building ambitious things.

Thanks for reading!
https://auralenz.vercel.app

"We need to rewrite everything from scratch." – said every CTO ever.

Thu, 21 May 2026 21:42:36 +0000

Sound familiar?

A legacy system is slow. Buggy. Nobody understands the code anymore.

The first instinct: Burn it down. Build it new.

But here's the problem with "rewrite from scratch":

It takes 2–3x longer than estimated
It costs a fortune (and then some)
It often fails (Google "rewrite from scratch disaster stories")
Your business doesn't stop while you rewrite

There's a better way.

Step-by-step modernization.
One module at a time.
No downtime.
Fixed price.
4–6 weeks.

My question to you:

Have you ever been part of a "big rewrite" project? How did it go? Success or disaster?

Let me know in the comments.

Building a Member Portal in Vue.js: Lessons from a Professional Association Project

Tue, 19 May 2026 11:30:26 +0000

Member portals look simple from the outside — log in, see your benefits, update your profile. The complexity is in the small things: session lifetimes, entitlement freshness, privacy compliance, and the fact that the people using it are members, not anonymous traffic, so the trust bar is higher.
I worked on the member portal for a national professional association (ALPFA Plus — membership.alpfaplus.org). The stack: Vue.js on the frontend, Axios for the API layer, lit-html for some templated rendering, AWS CloudFront for delivery, New Relic for real-user monitoring, and Osano for cookie consent. Here's what I learned.
Why Vue.js for a member portal
The decision came down to two things: the team's familiarity, and the portal's interaction model. Member portals are heavy on stateful UI — your profile, your benefits, your event registrations all need to stay coherent as you move between sections. Vue's reactivity model fits that work well, and the single-file-component approach kept the team productive without heavy tooling investment.
Axios + interceptors as the API contract
The portal talks to backend services for membership, billing, and benefits. Rather than scatter fetch calls through components, the API layer is built around Axios with a small set of interceptors:

Auth interceptor attaches the session token to every request and refreshes it transparently when needed
Error interceptor maps backend error codes to user-friendly messages and surfaces session expiry uniformly
Retry interceptor for transient failures (5xx, network errors) with exponential backoff

The win: every component calls api.getMemberProfile() and doesn't think about auth, retries, or error mapping. The plumbing is in one place.
Caching entitlements without going stale
The naive version of a member portal hits the API every time a benefits page loads. That's wasteful — entitlements change rarely. The smart version caches them, but then you risk showing stale state when a member upgrades their tier.
What works:

Cache entitlements client-side with a short TTL (a few minutes)
Invalidate aggressively on events that change entitlements (subscription change, plan upgrade, payment failure)
Provide a "refresh" affordance for members who feel like the portal is out of sync

Performance: where New Relic earned its keep
Real-user monitoring matters more on member portals than on marketing sites. Members come back repeatedly, so consistent performance shapes their long-term perception of the organization. New Relic's RUM gave us:

p75 and p95 page-load times segmented by route
JavaScript error rates per browser/version
API call latency from the user's perspective, not the server's

The thing that's easy to miss: server-side metrics lie about the user experience. A 50ms backend response can land in front of a member 800ms later if you've got render-blocking scripts or oversized bundles. Measure from the browser or you don't know.
Privacy compliance: Osano and the cookie banner question
Membership organizations sit in an interesting spot for privacy: members have given you contact information and consented to communication, but tracking them across the portal is a separate consent. Osano handles the consent UI and gates which scripts can fire based on user choice.
The implementation lesson: don't load Google Analytics, Google Tag Manager, or any tracker before consent. Wire them into the consent callback. It's tempting to "load and let Osano block them" — but that's not actually compliant in most jurisdictions, and it leaks data before the user has chosen.
Delivery via CloudFront
The build artifacts ship to S3 and serve through CloudFront. The CDN configuration that actually mattered:

Aggressive caching on hashed JS/CSS bundles (immutable, cache forever)
Short cache on the HTML shell (so deployments take effect quickly)
Custom error pages so 404s/500s don't look like an AWS outage
HTTP/2 and Brotli compression enabled (default on CloudFront now, but worth confirming)

What I'd do differently

More server-side rendering for SEO-relevant pages. Member dashboards don't need it, but the marketing-adjacent surfaces did.
A clearer separation between member and admin UI. Different access patterns, different performance needs, different bundles.
Earlier investment in component testing. Member portals get touched by support requests constantly; regressions in profile editing or benefit display are very visible. Tests pay for themselves quickly here.

Takeaways
If you're building a member portal:

Centralize the API client; don't scatter auth and retry logic through components
Cache entitlements but invalidate them on real events, not on a fixed schedule
Use real-user monitoring from day one; backend metrics lie
Wire privacy compliance into your script loading, not on top of it
Treat the member dashboard like a product, not a page

Happy to dig into any piece in the comments.

Currently Working on a Full-Stack Social Networking Platform

Wed, 15 Apr 2026 18:43:32 +0000

Currently Working on a Full-Stack Social Networking Platform

As part of my Web Development Internship at ARCH Technologies, I am currently working on Task 4 — a Social Networking Platform.

This project is focused on building a real-world application where users can create profiles, share posts, interact through likes and comments and connect with others — similar to professional platforms like LinkedIn.

Key Features:
• User Authentication with Email Verification
• Profile Management
• Posts, Likes & Comments
• Friend/Connection Requests
• Real-Time Notifications (WebSockets)
• Privacy Controls & Multimedia Sharing

️ Tech Stack:
Next.js • Node.js • Express • MongoDB • Socket.IO • Tailwind CSS

This project is helping me dive deeper into full-stack development and real-time systems while building something scalable and practical.

GitHub Repo: https://github.com/YasirAwan4831/arch-tech-task4-social-platform

More updates coming soon as I continue building

#WebDevelopment #FullStack #JavaScript #Nextjs #MongoDB #SocketIO #Internship #Projects #Learning #Internship #Projects #Learning #MuhammadYasir #YasirTech #YasirAwan

Title: Building LUMEN: A High-Contrast, AI-Powered Archival Network with Next.js & Supabase

Wed, 15 Apr 2026 15:52:54 +0000

Intro

I've always been obsessed with minimalist design—the kind that gets out of the way and lets the content breathe. Most blogging platforms today feel like social media: noisy, colorful, and distracting.

So, I built LUMEN. An archival publishing network where thoughts are preserved in a strict monochrome "Clean Canvas."

Live Demo: https://lumen-archive.vercel.app/
GitHub: https://github.com/Shyamkano/LUMEN

The Architecture

To keep the site fast and scalable, I went with a modern full-stack approach:

Framework: Next.js 16 (App Router) using the latest Turbopack for lightning-fast development.
Database & Auth: Supabase (PostgreSQL). I leveraged Row Level Security (RLS) heavily to ensure user data is private and secure.
Styling: Tailwind CSS v4 + Vanilla CSS for that crisp, brutalist look.
AI Engine: Mistral AI API for the "Editorial Co-pilot" which helps writers refine their work.
Rich Text: TipTap for a seamless, distraction-free writing experience.

What makes LUMEN different?

1. The Multi-Format Feed

Unlike standard blogs, LUMEN handles four distinct types of content:

Essays: Full-length long-form writing.
Micro-logs: Thoughts under 500 characters.
Code Gists: Shared snippets with full syntax highlighting.
Audio Chronicles: Voice logs with an integrated audio player.

2. The AI Editorial Assistant

I integrated a custom AI assistant that does more than just "chat." It can analyze your writing, suggest relevant tags, fix grammar, and even help you continue a narrative—all without leaving the editor.

3. Radical Privacy (Anonymous Identities)

LUMEN allows users to generate "Anonymous Identities." These are temporary aliases that let you publish a "Signal" (post) without it being traced back to your public profile, perfect for whistleblowing or raw, unedited thoughts.

What's Next?

LUMEN is open-source. I’m planning to add:

[ ] RSS Feed synchronization.
[ ] End-to-end encrypted private drafts.
[ ] Advanced full-text search using Postgres tsvector.

I'd love to hear your thoughts on the monochrome design. Is it too minimal, or just right?

Let's discuss in the comments below!

#showdev, #webdev, #nextjs, #supabase.

Engineering Real-Time Delivery Tracking That Increased Checkout Conversions by 20%

Thu, 09 Apr 2026 22:37:20 +0000

In e-commerce and on-demand delivery, the moment a user clicks "Place Order" begins an anxiety cycle. Where is my order? When will it arrive? This uncertainty kills conversions.

Between November 2020 and July 2021, I worked as a Full-Stack Developer at Viaduct, where I engineered a real-time delivery tracking system for an on-demand platform serving 5,000+ active users. The platform connected customers with local vendors for same-day delivery. Before I joined, users were abandoning carts and cancelling orders at alarming rates because they had zero visibility into delivery status.

This article details how I designed and built the tracking system — Google Maps integration, WebSocket-powered live updates, a Vue.js reactive interface, and the Laravel backend tying it together. The result: a 20% increase in checkout conversions.

The Problem: Delivery Opacity Was Killing Revenue

When I joined Viaduct, the delivery platform was functional but opaque. Users placed orders, received a confirmation email, and waited. The only updates were manual — a dispatcher marked orders "out for delivery" when a driver departed and "delivered" when reported back.

The consequences were measurable:

Cart abandonment: 32% of users abandoned at checkout. Exit surveys showed the top reason was "uncertain delivery time."

Post-order cancellations: 15% of completed checkouts were cancelled within 30 minutes, most citing "no delivery updates."

Support overload: 200+ daily calls asking "where is my order?" — each averaging 4 minutes, consuming 13 person-hours daily.

Driver accountability gaps: Without GPS tracking, there was no way to verify delivery times, identify route inefficiencies, or resolve disputes.

My Role: Full-Stack Architect of the Tracking System

I designed and built the entire real-time tracking system end-to-end: the Laravel backend infrastructure, Google Maps API integration, the WebSocket communication layer, and the Vue.js frontend tracking interface. I owned it from initial technical design through production deployment and post-launch optimisation.

Technical Deep Dive: Building the Real-Time Tracking Infrastructure

1. Driver Location Collection Architecture

The foundation of real-time tracking is reliable location data. I built a location reporting service on drivers' devices, transmitting GPS coordinates at configurable intervals.

class DriverLocationController extends Controller
{
    public function updateLocation(UpdateLocationRequest $request): JsonResponse
    {
        $driver = $request->user();
        $validated = $request->validated();

        $location = DriverLocation::create([
            'driver_id' => $driver->id,
            'latitude' => $validated['latitude'],
            'longitude' => $validated['longitude'],
            'accuracy' => $validated['accuracy'],
            'speed' => $validated['speed'] ?? null,
            'heading' => $validated['heading'] ?? null,
            'recorded_at' => Carbon::createFromTimestamp($validated['timestamp']),
        ]);

        if ($activeDelivery = $driver->activeDelivery) {
            $this->broadcastLocationUpdate($activeDelivery, $location);
            $this->updateEstimatedArrival($activeDelivery, $location);
        }

        return response()->json(['status' => 'recorded'], 200);
    }

    private function broadcastLocationUpdate(Delivery $delivery, DriverLocation $location): void
    {
        Redis::publish("delivery:{$delivery->id}:location", json_encode([
            'delivery_id' => $delivery->id,
            'driver' => [
                'latitude' => $location->latitude,
                'longitude' => $location->longitude,
                'heading' => $location->heading,
            ],
            'timestamp' => $location->recorded_at->toIso8601String(),
        ]));
    }
}

Location updates published to Redis channels, bridging the Laravel backend and the WebSocket server. This decoupled location ingestion (high-frequency HTTP POSTs from drivers) from location broadcasting (persistent WebSocket connections to customers), allowing each to scale independently.

2. Google Maps Integration for ETA Calculation

Accurate ETAs were critical. I integrated the Google Maps Directions API with live traffic data:

class GoogleMapsService
{
    public static function getDirections(array $origin, array $destination): ?DirectionsResult
    {
        $response = Http::get('https://maps.googleapis.com/maps/api/directions/json', [
            'origin' => "{$origin['lat']},{$origin['lng']}",
            'destination' => "{$destination['lat']},{$destination['lng']}",
            'mode' => 'driving',
            'departure_time' => 'now',
            'traffic_model' => 'best_guess',
            'key' => config('services.google_maps.api_key'),
        ]);

        if (!$response->successful() || $response->json('status') !== 'OK') {
            return null;
        }

        $leg = $response->json('routes.0.legs.0');
        return new DirectionsResult(
            durationMinutes: (int) ceil($leg['duration_in_traffic']['value'] / 60),
            distanceKm: round($leg['distance']['value'] / 1000, 1),
            polyline: $response->json('routes.0.overview_polyline.points'),
        );
    }
}

Using departure_time=now and traffic_model=best_guess ensured ETAs reflected live traffic — during rush hours, static estimates might show 10 minutes while actual time was 25. However, calling Google Maps on every location update (every 10 seconds per driver) would be prohibitively expensive. I implemented intelligent throttling using Haversine distance:

class ETAService
{
    private const ETA_CACHE_TTL = 60;
    private const MIN_DISTANCE_FOR_RECALC = 0.2; // km

    public function shouldRecalculateETA(Delivery $delivery, DriverLocation $newLocation): bool
    {
        if (!$delivery->eta_updated_at) return true;
        if (now()->diffInSeconds($delivery->eta_updated_at) < self::ETA_CACHE_TTL) return false;

        $lastCalcLocation = Cache::get("eta_calc_location:{$delivery->id}");
        if (!$lastCalcLocation) return true;

        return $this->haversineDistance(
            $lastCalcLocation['lat'], $lastCalcLocation['lng'],
            $newLocation->latitude, $newLocation->longitude
        ) >= self::MIN_DISTANCE_FOR_RECALC;
    }

    private function haversineDistance(float $lat1, float $lon1, float $lat2, float $lon2): float
    {
        $dLat = deg2rad($lat2 - $lat1);
        $dLon = deg2rad($lon2 - $lon1);
        $a = sin($dLat/2)**2 + cos(deg2rad($lat1)) * cos(deg2rad($lat2)) * sin($dLon/2)**2;
        return 6371 * 2 * atan2(sqrt($a), sqrt(1 - $a));
    }
}

ETAs were recalculated only when the driver moved 200m+ and 60+ seconds had elapsed, reducing Google Maps API calls by ~80%.

3. WebSocket Server for Live Customer Updates

The real-time frontend was powered by a Node.js WebSocket server subscribed to Redis channels:

const wss = new WebSocket.Server({ port: 6001 });
const subscriber = new Redis(process.env.REDIS_URL);
const deliverySubscriptions = new Map();

wss.on('connection', (ws) => {
  ws.on('message', (raw) => {
    const msg = JSON.parse(raw);
    if (msg.type === 'subscribe_delivery') {
      if (!deliverySubscriptions.has(msg.deliveryId)) {
        deliverySubscriptions.set(msg.deliveryId, new Set());
        subscriber.subscribe(
          `delivery:${msg.deliveryId}:location`,
          `delivery:${msg.deliveryId}:eta`,
          `delivery:${msg.deliveryId}:status`
        );
      }
      deliverySubscriptions.get(msg.deliveryId).add(ws);
    }
  });

  ws.on('close', () => {
    if (ws.deliveryId) {
      const subs = deliverySubscriptions.get(ws.deliveryId);
      if (subs) { subs.delete(ws); if (subs.size === 0) deliverySubscriptions.delete(ws.deliveryId); }
    }
  });
});

subscriber.on('message', (channel, message) => {
  const [, deliveryId, eventType] = channel.split(':');
  const subs = deliverySubscriptions.get(deliveryId);
  if (!subs) return;
  const payload = JSON.stringify({ type: `delivery_${eventType}`, data: JSON.parse(message) });
  for (const ws of subs) { if (ws.readyState === WebSocket.OPEN) ws.send(payload); }
});

The server was deliberately stateless — it bridged Redis pub/sub to WebSocket connections with no business logic, making it horizontally scalable.

4. Vue.js Real-Time Tracking Interface

The customer-facing tracking page used Vue.js Composition API. The core was a WebSocket composable with exponential backoff reconnection:

export function useDeliveryWebSocket(deliveryId) {
  const driverLocation = ref(null);
  const eta = ref(null);
  const deliveryStatus = ref('confirmed');
  let ws = null, reconnectAttempts = 0;

  function connect() {
    ws = new WebSocket(process.env.VUE_APP_WS_URL);
    ws.onopen = () => {
      reconnectAttempts = 0;
      ws.send(JSON.stringify({ type: 'subscribe_delivery', deliveryId }));
    };
    ws.onmessage = ({ data }) => {
      const msg = JSON.parse(data);
      if (msg.type === 'delivery_location') driverLocation.value = msg.data.driver;
      else if (msg.type === 'delivery_eta') eta.value = msg.data.eta_minutes;
      else if (msg.type === 'delivery_status') deliveryStatus.value = msg.data.status;
    };
    ws.onclose = () => {
      if (reconnectAttempts < 10)
        setTimeout(connect, Math.min(1000 * 2 ** reconnectAttempts++, 30000));
    };
  }
  return { driverLocation, eta, deliveryStatus, connect, disconnect: () => ws?.close() };
}

The map component initialised Google Maps, rendered destination and driver markers, and animated the driver marker between positions using cubic easing. Without animation, the marker would "teleport" every 10 seconds — with smooth interpolation, users perceived continuous movement, dramatically improving perceived quality.

5. Delivery Status Lifecycle and Performance

Every status transition published to Redis for real-time updates, sent push notifications, and recorded metrics:

class Delivery extends Model
{
    public function markPickedUp(): void
    {
        $this->update(['status' => 'picked_up', 'picked_up_at' => now()]);
        Redis::publish("delivery:{$this->id}:status", json_encode([
            'delivery_id' => $this->id, 'status' => 'picked_up',
            'driver' => ['name' => $this->driver->name, 'phone' => $this->driver->phone],
        ]));
        $this->order->customer->notify(new DeliveryPickedUpNotification($this));
    }

    public function markDelivered(): void
    {
        $this->update(['status' => 'delivered', 'delivered_at' => now()]);
        Redis::publish("delivery:{$this->id}:status", json_encode([
            'delivery_id' => $this->id, 'status' => 'delivered',
        ]));
        $this->order->customer->notify(new DeliveryCompletedNotification($this));
        DeliveryMetric::create([
            'delivery_id' => $this->id, 'driver_id' => $this->driver_id,
            'estimated_minutes' => $this->estimated_arrival_minutes,
            'actual_minutes' => $this->picked_up_at?->diffInMinutes($this->delivered_at),
        ]);
    }
}

The DeliveryMetric model enabled comparing estimated vs. actual delivery times, identifying underperforming drivers and slow routes.

For performance at scale, I buffered location writes in Redis and flushed to PostgreSQL in batches every 30 seconds, reducing database write load by 90% while maintaining real-time delivery through the pub/sub layer. Vendor discovery pages used PostGIS spatial queries (ST_DWithin, ST_Distance) with aggressive caching, returning results in under 50ms across thousands of records.

The Results: Measurable Business Impact

The system launched after eight weeks of development. Results over a 60-day observation period:

Metric	Before	After	Change
Checkout conversion rate	68%	88%	+20 percentage points
Post-order cancellation rate	15%	4%	73% reduction
"Where is my order?" support calls	200+/day	~35/day	82% reduction
Customer satisfaction score	3.4/5	4.3/5	26% improvement
Active platform users	~3,200	5,000+	56% growth
Tracking page views per order	0	4.2	New engagement channel

The support call reduction alone freed 11 person-hours daily — redirected to proactive customer outreach and vendor management.

Technical Lessons

Decouple ingestion from delivery. Location collection (Laravel) and broadcasting (Node.js WebSocket) had different performance profiles. Separate services connected by Redis allowed independent scaling.
Animate transitions, don't teleport. Users perceive smooth movement as real-time tracking and position jumps as a broken system.
Throttle expensive API calls intelligently. The Haversine check before ETA recalculation saved thousands of unnecessary Google Maps calls daily.
Buffer writes, stream reads. Batch-writing to the database while streaming through Redis provided both persistence and live performance.
Measure business metrics. WebSocket latency matters, but checkout conversion rate proved the system's value.

I Built A Full-Stack App in 7 Days: Here’s Day 1

Tue, 07 Apr 2026 07:02:30 +0000

I decided to challenge myself in a way that I have been considering for a while now. Build a full-stack application in only 7 days, completely from scratch, to completely real and usable. Not just a tutorial project, a clone of something that already exists, but something that I have designed, created, and shipped by myself.

There’s something about coding projects like these that make them feel almost deceptively simple in the beginning. You think the hard part will be writing the code, but in reality, the hardest part is normally finishing them. Most people don’t fail because they can’t write the code… they fail because they never fully complete anything. They always stop somewhere between ‘idea’ and ‘almost done’.

So, I wanted to remove that entirely. I stuck to no over-planning, no perfect architecture diagrams, and no time wasted endlessly researching the ‘best possible’ stack. Just 7 days of building, documenting and continuing on forwards no matter what happens. This is Day 1.

Day 1 started almost exactly like you would expect. I was staring at my laptop’s blank screen, trying to decide what I was going to build. This part is always more difficult than people admit. Not because it is necessarily difficult to think of ideas, but because it feels like you have to have the perfect idea before you even begin.

However, I forced myself to follow one simple rule: if I couldn’t explain the project in one sentence, and why I wanted to build it in one more, then I wasn’t allowed to build it yet. That alone removed a lot of the noise. After cutting everything down, I ended up with a relatively simple direction: build a full-stack app that is actually useful, is small enough to build in one week, but also flexible enough that I can expand it later.

It was nothing revolutionary, just something real that I could actually build and improve on. So, once I had that clarity, I stopped planning and started building almost immediately.

For the first day, I didn’t focus on building features. I focused instead on setting up my foundations properly so I wouldn’t regret it later on down the line.

I chose a stack that prioritised both speed and simplicity: Next.js for both the frontend and backend, Supabase for authentication and database, and TailwindCSS for styling. I decided not to waste time deciding about tools; I just picked what let me move quickly.

I created the project, set up the basic structure, connected Supabase, and got the environment variables working. It doesn’t sound like a lot on paper, but this is the stage, when developing something new, that everything either goes smoothly or starts to become a mess later on.

There always happens to be a moment during the setup where things feel slightly messy and fragile, like one wrong configuration could break everything. But, after a bit of trial and error, I got it running cleanly.

That moment when the app finally boots without errors is always underrated. It is the point, where for the first time, the project stops being an idea, and begins to transform into something real.

My biggest win on Day 1 wasn’t building a feature, or writing some complex logic. It was simply getting everything to connect properly. The front-end loaded correctly. The backend responded. The connection to the database worked. There were no errors flooding my terminal.

It sounds basic, but these small confirmations mattered more than anything else early on to me. They were the things that gave me momentum. Without that, each of the next steps I took would have felt uncertain. Instead, everything felt possible.

Of course, my Day 1 wasn’t completely smooth. Even on Day 1, I ran into the usual setup issues: Environment variables wouldn’t load properly, there was some confusion over my Supabase setup, and some smaller decisions about folder structures that, looking back, I probably spent way too long thinking about. Nothing too major, just enough to slow things down only a little.

What I found most interesting was that most of these problems weren’t actually problems related to coding. They were setup problems. And setup problems always feel worse than they actually are, because they block everything else from moving forwards. Once I had that realisation, it became a lot easier to stay calm and focus on fixing things one by one, instead of overreacting and panicking.

Looking back at the first day, the main lesson I took from it wasn’t technical at all. It was all about my speed and momentum.

It reminded me that planning is only useful up to a certain point. After that, it becomes a delaying tactic cleverly disguised as productivity. Progress only really starts when you begin to build something that exists outside your head.

It also reinforced something that I have noticed before: that getting something running, even if it is in its most basic form, is far more important than making it perfect. Perfection can come later, but functionality has to come first.

Most importantly, it showed me that momentum is everything. Once the project is alive, even in a basic form, it becomes much easier to continue.

Day 2 is where things will start to get interesting.

Now that the foundation is in place, I will start to build actual features: real UI components, authentication flows and the first real pieces of functionality that turn my project from just a setup into something users could actually interact with.

Right now, I have the scaffolding. By Day 2, it starts to become a product.

If you enjoyed this post, make sure to subscribe so you can follow everything I’m building in real time.

Also, check out My SubStack, where I am turning this into a 7 part weekly series.

lucybatten.substack.com

If you have any questions, connect with me on LinkedIn:

lucybatten

If you want to see how ideas turn into real apps (and what ends up happening along the way), check out the rest of the posts in this series.

More builds, more problems, and more fixes… coming every week.

How to Become a Web Developer in 2026: Ultimate Guide to Skills, Tools & Career Growth

Fri, 23 Jan 2026 10:48:40 +0000

The world of web development is evolving rapidly, and 2026 promises to be an exciting year for aspiring developers. If you want to build a successful career in web development, it’s not just about knowing HTML, CSS, and JavaScript anymore. Today, modern web developers need a mix of frontend and backend skills, an understanding of AI-assisted development, and the ability to create real-world projects that showcase their expertise.

This comprehensive guide walks you through everything you need to know: starting from the fundamentals, diving into popular frameworks like React and Next.js, exploring backend technologies such as Node.js, Django, or FastAPI, and managing databases like MongoDB, MySQL, or PostgreSQL. You’ll also learn how to deploy projects to cloud platforms, implement CI/CD pipelines, and maintain code quality with tools like ESLint and Prettier.

AI is reshaping development workflows, from coding assistance with ChatGPT or GitHub Copilot to automated testing and design tools. By learning to leverage these technologies, you’ll work smarter, build faster, and stay ahead of the competition.

We’ll also guide you on building projects, creating a strong portfolio, contributing to open-source, and networking in developer communities. Whether you aim to land your first remote job, freelance clients, or grow into a full-stack developer, this roadmap will equip you with the knowledge, skills, and confidence to thrive as a web developer in 2026 and beyond.

The Journey of Enoch Philip Dibal: Building with Code and Purpose

Tue, 25 Nov 2025 23:32:15 +0000

Enoch Philip Dibal is a software engineer and writer. His work shows patience, focus, and a drive to learn. He builds for the web, writes technical content, and studies computer engineering.

Early focus on learning
From the start, Enoch made learning his priority. He took each tool and framework step by step. JavaScript, React, Node, and databases became his toolkit. Instead of rushing, he mastered the basics before moving forward.

Building as a way of thinking
For Enoch, building is not only about output. It is a way to think clearly. By turning ideas into working projects, he improves his mind and his craft. Each project is proof of consistency.

Balancing software and engineering study
While studying computer engineering, he applies theory in practice. Academic work builds his foundation in systems and hardware. Software projects give him speed in execution. The two sides make his path stronger.

Writing as part of growth
Enoch does not stop at coding. He also writes. His writing is direct, simple, and structured. By writing technical posts and documentation, he helps others learn while reinforcing his own knowledge.

Principles he works by
Learn fast but with depth
Keep focus on clarity
Write simple and functional code
Share knowledge through writing

"Code is a tool. The goal is to solve problems with accuracy and
patience."

Recent projects
Enoch has worked on full-stack applications with authentication, dashboards, and APIs. He also experiments with design and user experience. Each project reflects careful structure and focus on usability.

Challenges and lessons
Like all developers, he faced errors, failed builds, and slow progress at times. Instead of quitting, he treated each obstacle as part of the path. Debugging improved his patience. Deadlines taught him planning. Team work improved his communication.

Vision for the future
Enoch’s vision is not limited to personal success. He aims to mentor, to teach, and to support others entering the field. He believes consistent learning and clear writing create long-term impact.

Closing note
Enoch Philip Dibal is still in motion. His story is not complete. Each new line of code, each article, each project adds to the journey. What stands out is his clear focus: learn, build, share.

StackDAG

Sat, 16 Aug 2025 19:43:05 +0000

It’s been three weeks since StackDAG launched into public beta, and the community keeps growing. Thanks to everyone who’s been building stacks, sharing ideas, and making this project better every week.

StackDAG is a platform for building and sharing application stacks using Directed Acyclic Graphs (DAGs). You can model anything from a traditional PERN stack (React, Express, Node.js, PostgreSQL) to a completely custom workflow using a flexible, visual DAG editor.

Here’s what’s new in Week 3:

New Components: Several new component nodes have been added, including Google Maps. Keep the suggestions coming, as many of these additions are driven directly by feedback from the community.

Security Fixes: A few more issues were patched this week. As always, if you notice anything unusual or potentially vulnerable, please reach out. Early feedback is incredibly valuable.
Visual Improvements: A handful of visual bugs were fixed, along with small UI tweaks to make StackDAG smoother to use.

Weekly Challenge 2

Submissions are in, and now it’s time to vote! Join the Discord to see the entries, cast your vote, and take part in future challenges: https://discord.gg/VqwqHmg5fn

And a quick community shoutout: People are already using StackDAG to plan out their apps and even asking for advice in here. I couldn’t be prouder of how collaborative and supportive this community is becoming.

Join the Beta: Start building your first DAG at https://stackdag.pages.dev

During the beta, you’ll get access to:

DAG templates to get started fast
A broad set of components to build any stack
Sharing and forking tools to collaborate or remix ideas
A feed of trending DAGs from the community

During the beta, all accounts get marked as early testers and will receive early access to upcoming premium features.

Thanks again for being part of StackDAG’s journey. Let’s make Week 4 even bigger.

React Native to Microservices

Tue, 22 Jul 2025 21:14:32 +0000

In the React Native world we pretty much only worry about calling an endpoint and receiving some data from such endpoint. We are usually blind to all the work that happens in retrieving this data. In this post I am going to trace the api call from when it leaves the device up until the response is received, in a microservices context — naive point of view.

The api call goes to a domain name server to resolve where this api call should go. If I am in Italy, the api call will go to the nearest load balancer around Italy. This is enabled by having geolocation routing.

After the nearest load balancer has been identified. The api call is taken to this load balancer. A load balancer makes sure that when too many users are on their beds watching tiktoks the servers are not overloaded with too many requests at once. It distributes the requests in a manageable manner.

The load balancers can also route the api request to the server that is responsible for processing the request. For example, /videos/1 should go to the videos server instead of the pictures server. The load balancer will then take the /videos/1 request to the videos server.

Once the api request has arrived at the videos server, this server will also communicate with other microservices, maybe analytics, views count, metadata, related videos, and such. The Synchronous part of the request will return to the react native app, the video data and metadata for example, on the other hand, the asynchronous part, analytics for e.g., usually make use of something called message queues to communicate with the other microservices.

Message queues ares queues usually read by other microservices, analytics, metadata, recommendations, each can be subscribed to a message queue. Message queues are ideal because if the service goes down, the message queue will hold the message until the service comes back up and acknowledges the message was processed. This prevent’s losing messages along the way.

This is a high level overview, there is so much in between these processes; ssl, caching, routing algorithm, message exchange, producer, broker, CAP theorem, rate limiting, and so much more.

Building a HTTP Server from Scratch: Know the HTTP principles to be a better FS Developer

Mon, 09 Jun 2025 18:45:18 +0000

Why Build a HTTP server from Scratch?
First, the basics. What Is an HTTP Server?
- TCP vs. UDP
Key features of my HTTP Server (Typescript + Nodejs)
What I Learned
What’s Next?
Why It Matters - Meta Learnings

Why Build a HTTP server from Scratch?

These days, you can spin up a fully functional server in minutes with the help of modern tools.

Why would anyone bother building an HTTP server from scratch using NodeJs and Typescript?

For me, it's an experiment I am running for the next three months: mastering building blocks fundamentals and re training myself on doing deep work.

There is also a simple truth about working in tech: if I am serious about thriving as a full-stack engineer, I surely need to own the basics, and not just know how to work with abstractions and frameworks that do pretty much everything for you.

Beyond the technical challenge, there’s the simple satisfaction of building something fun and tangible. There’s unparalleled satisfaction in crafting a tool that serves a real purpose, like delivering a web page that serves an HTML page with images and text, using only the basics.

It’s a powerful way to deepen your technical skills in a meaningful way while working on something enjoyable.

First, the basics. What Is an HTTP Server?

At its core, an HTTP server is a program that listens for incoming HTTP requests from clients (like a browser or API consumer), processes those requests, and sends back responses. It uses the TCP (Transmission Control Protocol) to establish a reliable connection, ensuring that data packets arrive in order and intact.

TCP vs. UDP

I do mountaineering and one analogy came to me to differentiate TCP and UDP protocols.

TCP: Think of climbers on a glacier roped together. Everyone reaches the summit securely and in order. That’s TCP: ensuring that data (climbers) arrive in order and intact.
UDP: UDP are like alpinists climbing individually without ropes. It’s usually faster, but there’s no guarantee everyone gets there. Fast, but less reliable.

Key features of my HTTP Server (Typescript + Nodejs)

Handles GET and POST Requests: Responds with a simple “Hello, World!” for basic requests.
Supports for HTTP/1.1 Protocol: Implements the essentials of this widely-used protocol.
Serves Static Files: Fetches and delivers image files stored in the server’s public/images/ directory.
Routing: Implements basic routing using if-else statements to handle different endpoints like /api or /.
Error Handling: Ensures proper responses for malformed requests, like returning 400 Bad Request for parsing errors.

What I Learned

Learning 1: Sockets!

Sockets are how servers and clients talk to each other. Before this project, I knew about sockets the way most of us know about cars: we press the gas pedal, and the car moves. Magic! Now, I’ve seen how there is nothing magical about it, especially when I wrote the createDataHandler function:

const createDataHandler = (
  socket: net.Socket,
  handleRequest: (rawRequest: string) => {
    statusCode: number;
    statusMessage: string;
    headers: Record<string, string>;
    body: string | Buffer;
  },
): ((chunk: Buffer) => void) => {
  let buffer = '';
  
  return (chunk: Buffer) => {
    buffer += chunk.toString();
    if (buffer.includes('\r\n\r\n')) {
      const response = handleRequest(buffer);
      if (socket.writable) {
        socket.write(formatHttpResponse(response));
        socket.end();
      } else {
        logger.error('Socket is not writable, skipping response');
      }
    }
  };
};

Explanation of `createDataHandler` Function

createDataHandler is a function that handles incoming TCP data chunks for HTTP requests. It maintains a buffer—a string that accumulates data from incoming chunks.

Chunk Conversion: For each chunk, it converts the binary data into a string and appends it to the buffer.
Header Detection: It then checks if the buffer contains \r\n\r\n, which marks the end of the HTTP headers.
Processing & Response: If it finds the marker, it processes the request and sends a response.

This gave me a clearer view of how HTTP works at the lowest level: every incoming request starts as raw data, and the server has to parse it into something usable. Sockets are the invisible ropes that pull these chunks back and forth, and the createDataHandler function is the intermediary which makes something sensible of the data.

We can also appreciate how fragile things are: if the buffer isn’t handled properly—by failing to detect the end of the headers, for example—the server breaks. These are things I've never appreciated when using frameworks.

Learning 2: Routing Isn’t That Simple

Manual routing turned out to be more challenging than I expected, especially when it came to handling content types. Frameworks like Express.js make this super easy, but behind the scenes, there’s a lot happening:

Content-Type Handling: My server only supported JSON for request bodies, and I had to set the correct MIME type manually for responses. Adding support for more content types, like multipart/form-data for file uploads or application/x-www-form-urlencoded for form submissions, would require additional parsing logic.
Headers Management: In a basic setup, you’re responsible for setting essential headers like Content-Type and Content-Length. Get these values wrong, and the client either won’t understand the response or will hang waiting for more data. This is what happened when my server was not picking up the images/jpeg datatype.
Parsing Body Formats: Each content type requires its own logic. For example, JSON bodies need to be parsed into JavaScript objects, while multipart/form-data requires handling file streams. This complexity grows quickly as you add support for more formats.

Express.js automates most of this. It detects the Content-Type header, parses the body accordingly, and sets the right MIME type for responses. Doing this manually gave me a deep appreciation for how much work frameworks save.

While my manual routing works for basic cases, it’s clear that scaling it to handle more complex scenarios would require more effort.

Learning 3: Always Try to Break Your Software

Software is rarely perfect the first time around. A great way to test my server was to run:

hey -n 1000 -m GET http://localhost:8080/

Stress Test Outcome

BOOM. The server crashed after 800 requests.

Why?
This command sends 1,000 simultaneous GET requests, simulating real-world stress. It exposed a critical issue: I wasn’t handling socket timeouts properly. My server would hang because it didn’t close idle sockets.

The Fix:
To fix this, I chose to close the socket after each request, which works great for the scope of this project. But if I wanted to support persistent connections, I’d need to avoid calling socket.end() and implement additional logic. For now, closing the connection after each request is the simplest and safest approach. It’s clean, predictable, and prevents resource leaks.

What’s Next?

There’s a lot more I can add to this server, which is also the reason why I love to start a project from ZERO. I get to own every bite of it and can add on to it as learning-needs/curiosity fit.

HTTPS: Right now, it’s plain HTTP. Adding SSL/TLS would make it secure.
WebSockets: For real-time communication, like chat apps.
Authentication: Handle user logins and sessions.
Better Routing: Add support for more content types and dynamically set MIME types based on file extensions or request content.
Caching: Improve performance by storing frequently requested data.

Why It Matters - Meta Learnings

I am a huge fan of Tim Ferriss, especially when it comes to his lessons on meta learning, or the ability to learn pretty much everything and become a top performer in any field in a short period of time.

Writing an HTTP server from scratch was a way to dig deeper into one of the fundamental building blocks of full-stack engineering—to deeply understand the web and servers. It was also interesting to see how constraints (not using a framework like Express) force you to think critically and solve problems creatively, which of course deepens my understanding. Last but not least, there’s simply a unique joy in building something functional from scratch!

You can check the project on GitHub!

Happy building!