DEV Community: Ch. Abdul Wahab

Why We Started Systemset: Building Smarter Tools for Modern Businesses

Ch. Abdul Wahab — Sun, 19 Apr 2026 04:52:26 +0000

Our journey to make work simpler, faster, and growth-driven through smart systems.

In today's fast-moving digital world, every business and developer needs the right set of tools to succeed. But there's a problem:

Either the right tools don't exist in the market, or if they do, they're too expensive and out of reach for students, small startups, and even independent developers.

This is where the idea of Systemset was born.

From Personal Need to Bigger Vision

Over time, we often found ourselves in situations where we needed specific tools — but couldn't find anything affordable or accessible. Many times, we had to build our own solutions just to handle daily challenges.

That's when we realized: if we are struggling with this problem, so are thousands of students, startups, and developers around the world.

Instead of keeping our solutions to ourselves, we decided to build a platform where anyone can access powerful, easy-to-use, and affordable digital products.

Building a Strong Community

One of our biggest inspirations has been platforms like Stack Overflow — places where people come together to learn, share, and grow.

Through this initiative, we aim to bring students and developers onto a single platform where they can:

Collaborate
Discuss
Share ideas
Build real products — even while still studying

We believe that if students start building meaningful products early, they won't just learn faster — they'll also create tools that can make a difference in the world.

Our Vision

At Systemset, our vision is simple:

Create products that don't exist in the market yet
Deliver them at a cost that makes sense for everyone
Empower students, developers, and businesses to succeed without barriers

We don't claim to be the only ones building these kinds of products. Others may be doing excellent work too. But what we promise is this: we will always strive to give you the best possible products, at the most affordable cost.

The First Step of a Long Journey

This is just the beginning.

Systemset is not just about software — it's about building a movement where technology, community, and affordability come together.

If you're a student, a developer, or a business trying to do more with less, we're building this for you.

Let's create the future, together.

Are you a better Dev than yesterday?

Ch. Abdul Wahab — Sun, 19 Apr 2026 03:43:16 +0000

Let me ask you something honest.

Are you a better developer today than you were yesterday?

Not better as in "I know more frameworks" or "I've watched more tutorials." I mean genuinely better — did you understand something today that you didn't understand yesterday? Did something click?

If your answer is yes, keep doing what you're doing. You're on the right path.

But if your answer is no — or worse, if you had to think about it for a while — then I want to ask why. Because the reasons are usually the same: no time because of a 9-to-5, an internship eating up your energy, studies leaving no room, or just the quiet exhaustion of trying to keep up with a field that never slows down.

I get it. I've been there. I'm still there, in some ways.

I'm an IT trainer at the same institute where I once sat as a student. Outside of that, I build products solo under my own company — mobile apps, web apps, UI/UX, system design, the whole thing. Several of those apps are live right now. You'll find the links at the end of this post.

So when I talk about this workflow, I'm not theorizing. I use it every day.

Stop Being Afraid of Vibe Coding

Here's something that bothers me about the dev community right now.

There's a section of developers — especially those who've been in the field since before AI was useful — who treat Vibe Coding like it's cheating. They still write everything manually, and somewhere in the back of their mind, they believe that's what makes them "real" developers. They worry that if they use AI to build something, people will say: "What did you even do? The AI did everything."

I understand that feeling. But that thinking is holding people back.

No one looks at an architect and says, "You didn't build the building yourself, so you're not a real architect." The architect designed it, specified it, made the decisions, caught the mistakes, and took responsibility for the outcome. The workers executed.

AI is a worker. A very fast, very capable worker. But it still needs someone who knows what they want, can catch when it's wrong, and can redirect it when it goes off track. That someone is you — if you're willing to actually learn the craft underneath.

The Learning Method That Actually Works

Here's exactly how I learn, and how I'd tell you to learn.

Get a fresh notebook and a pen. Open two tabs in your browser — one for a chatbot, one for the official documentation of whatever you're studying. Not a YouTube tutorial. Not a course. The actual docs.

Read the documentation. Even if you don't understand it fully. Especially if you don't understand it fully.

When you hit a word you don't know, copy it into the chatbot and ask for a plain explanation. Then write that word and its meaning on the right side of your notebook page. You're building your own offline dictionary — one you actually remember because you built it yourself.

On the left side of that same page, write what you're learning in your own words. Messy, broken, incomplete — it doesn't matter. The act of writing forces your brain to translate what it read into something it actually understands.

Let me give you a real example. If you're starting with Node.js, don't jump straight into building an API. First, just understand: what is npm? What is nvm? What is npx? What is a software registry? How are these things different from each other, and why does each one exist?

Just understand. Don't build yet.

Then, once something makes sense — do one small practical thing with just that concept. Run it. See the output. Watch the program do what you just learned it should do.

That moment — when the output matches your understanding — is the moment your brain stores it permanently. Not because you memorized it. Because you experienced it.

Be Consistent. Don't Jump.

This is the part most people skip.

Don't move to the next topic until the current one makes sense. I don't care if someone tells you that you're going too slow. I don't care if AI can do the whole thing in 30 seconds. You stay with that concept until it's yours.

Because here's what happens when you're consistent: after a few weeks, you'll start feeling something shift. You'll be in a conversation with other developers and realize you're the one explaining things. You'll look at a codebase and actually understand what's happening instead of just hoping it works. You'll feel a kind of confidence that's different from arrogance — it's the confidence of someone who knows their own work.

That feeling is real. And it only comes from not skipping steps.

Now, About Building With AI

Once you have that foundation — even a small one — here's where things get exciting.

When an idea for an app comes to you, don't dismiss it because you think you're "not ready." Draw it out. Make a rough flowchart. What are the screens? What does the data look like? What happens when a user does X?

Then take that understanding and give it to an AI agent. Not as a vague prompt like "build me an app." As a technical spec. Tell it what stack to use, what the data structure should look like, what libraries are appropriate, what you want each function to do.

And then watch it work — not passively, but actively. Question every decision it makes. Ask it why it chose one approach over another. When something looks wrong, push back. You are the manager. The AI is executing.

This is not Vibe Coding. Vibe Coding is throwing a vague idea at an AI and hoping for the best. What I'm describing is technical leadership — using a powerful tool while staying in full control of the outcome.

And here's the thing: the more technical you become, the better your prompts get without you even trying. You'll naturally start specifying tools, libraries, architecture patterns — because you understand them. That's prompt engineering, but it emerges from real knowledge. You don't have to study it separately.

Ship It. Then Own It.

When the app is ready — ship it. Cloudflare Pages, free tier, your own subdomain, live in minutes. No excuses.

And when it's live, introduce it with confidence. "I built this." Not "AI built this" and not "I wrote every line myself." The truth: you built this, with AI as your tool.

If someone says "the AI did it," your answer is simple: "The same AI is available to you. Why haven't you built yours?"

Because here's the real differentiator — it was never about who wrote the code. It's about who understood the problem, made the decisions, and shipped the product.

Where I Am Right Now

Everything I've described in this post is how I built these:

Acadly — A school communication app
Deal Safe — An escrow platform connecting clients and freelancers
Projex CLI — A Python library that generates boilerplates straight from your terminal
Tron — A GUI-based QA testing tool

Go check them out. See if anything looks AI-generated to you. I'll wait.

You don't have to pick between learning deeply and building fast. The workflow exists. It just takes consistency, honesty about where you are, and the willingness to be the one in charge — not the AI.

That's it. That's the whole thing.

Part of an ongoing series on building real things and learning the hard way.

Turns out free doesn't mean unlimited 🔥

Ch. Abdul Wahab — Sat, 18 Apr 2026 12:56:55 +0000

There's a moment in every developer's journey where you stop asking "can I build this?" and just... build it. No overthinking, no analysis paralysis. Just a problem in front of you and a keyboard under your hands.

Mine came from the most unexpected place: a maths and physics teacher at the school where I work as an IT trainer.

"Sir, why is there no app where students and teachers can talk separately? WhatsApp is a mess — work stuff, jokes, random forwards, all in one place."

He was right. I'd felt it too. So I said, "Let me think about it." And then I just started building.

What I Built (And What It Became)

The app is called Acadly — yes, I know a similar name exists in the market, but this is a completely different product, and the name isn't final yet. I'm open to suggestions after you read this.

The idea was simple: a focused communication platform for schools. Four sections:

Chat — personal and group messaging between teachers and students, with file sharing built in
Files — each user gets their own folder, can upload files, and others can view or download them
Members — a directory of everyone in the system, organized by role
Profile — manage your identity, privacy, and settings

As the app grew, so did the features. We added a read-only announcement channel at the top — only Team and Admin could post, everyone else just read. We added Admin controls: lock users who violate rules, delete files or messages, restrict actions entirely for bad actors. A locked user couldn't message anyone, create folders, or even change their profile picture.

For privacy, users could hide their email — it would display as *******@example.com unless they chose otherwise.

We even added a small engagement layer: teachers who actively responded to students earned achievement badges, and students could rate each other for helpfulness — a rating only visible to other students, not to teachers, and not even to the rated student themselves.

It was working well. People were using it. The vibe was good.

The Database Journey (Where It Gets Interesting)

Here's the part I want every mobile developer to read carefully.

I started with Firebase. It's familiar, it has a great free tier (Spark Plan), and the Google sign-in flow is genuinely smooth. On the free plan you get:

50,000 document reads/day and 20,000 writes/day on Firestore
1 GB storage on Cloud Storage
50,000 monthly active users for authentication

Sounds generous — and it is, for small apps. But here's what I didn't implement that cost me later: offline caching.

Modern apps are smart about this. When you open them, they serve you cached data from your local storage first, then quietly fetch only the new stuff in the background. You can even read messages in flight mode if the data is cached. I didn't set this up. So every time a user opened the app, it fetched everything from Firebase fresh. Every. Single. Time.

When the daily read limits hit, messages stopped sending. The app just... stopped.

Now, to be fair — I had only shared the app internally with a small group of users, and I'd warned them not to use it for anything critical yet. So no real damage was done. But the lesson was clear.

For file storage, I moved to Supabase, which made sense because:

500 MB database storage on the free plan
1 GB file storage
50,000 monthly active users
Max file size of 50 MB per file on the free tier
Projects pause after 1 week of inactivity (something to watch out for)

Supabase handled files well. But the real question was: what comes next?

Why I'm Moving to Cloudflare (R2 + D1)

After going back and forth between Firebase and Supabase, I made a decision: Cloudflare R2 and D1.

Here's why this combination clicked for me:

You get a SQLite database (D1) that you can deploy and manage entirely through Cloudflare's wrangler CLI. No separate backend hosting. No managing servers. Your entire full-stack web app — frontend on Cloudflare Pages, backend Workers, database on D1, files on R2 — all deployed from the terminal. The deployment headache just disappears.

The free tier is genuinely good:

Cloudflare Workers: 100,000 requests/day, resets at midnight UTC
R2 storage: 10 GB free, with no egress fees (yes — no charges for downloading your own files)
D1 database: generous read/write limits on the free plan
Cloudflare Pages: static asset requests are unlimited and free

And all of this is free. No credit card required to get started.

I hadn't used R2 or D1 when I was building Acadly. I knew the names, but hadn't touched them. Then I decided I was going to make it work, sat down, figured it out, and now I'm recommending it to anyone building a full-stack app who doesn't want to juggle three different hosting services.

The Lesson Behind All of This

When I look back at the entire Acadly journey, the real lesson isn't about which database to pick. It's about what happens when you decide you're going to build something no matter what.

You end up learning things you wouldn't have learned from a tutorial. Firebase limits teach you about caching. Supabase file limits teach you about storage architecture. Cloudflare teaches you that serverless deployment doesn't have to be painful.

Every constraint pushed me toward a better decision.

If you're building a mobile app — React Native or otherwise — here's what I'd tell you:

Set up offline caching from day one. It's not a nice-to-have. It's the difference between an app that works and an app that hammers your database on every open.

Know your free tier limits before you hit them. Firebase's daily read/write quotas reset at midnight Pacific. Supabase's free projects pause after a week of inactivity. Cloudflare Workers reset at midnight UTC. These aren't gotchas — they're just information you need upfront.

And if you ever feel stuck on a dashboard or config panel — here's my actual trick: Ctrl+A, Ctrl+C, paste it into any AI chatbot, and ask "I want to do X here, how?" It saves hours of YouTube tutorials and gets you moving again fast.

Acadly is still in development. The name might change. The database definitely changed. But the problem it's solving — keeping school communication clean and organized — that hasn't changed at all.

If you've built something similar or have thoughts on the stack, drop it in the comments.

Check it out: Acadly

Part of an ongoing series on building real things and learning the hard way.

We Started a Startup, Got One Client, and It Broke Us Apart

Ch. Abdul Wahab — Fri, 17 Apr 2026 07:37:04 +0000

I want to tell you about the most chaotic, frustrating, and honestly hilarious chapter of my life as a developer.

The Job That Taught Me Everything (Except Boundaries)

Before all of this, I was working at a company as a Python Developer. Junior title, but the work was anything but junior. I ended up handling Cloudflare security, cloud integrations, API integrations — things way outside my job description. Nobody asked me to. I just did it because someone had to.

Looking back, that job gave me a dangerous amount of confidence. I thought I could handle anything.

Eventually things went sour with our team lead. He ran the team like a closed room — no opinions, no pushback allowed. That's a story for another post. But leaving that place felt like breathing fresh air for the first time.

So naturally, we decided to start a company.

The Google Meet That Started Everything

It was 2024. Late night. Four friends on a Google Meet call.

My friend painted the picture: "It's just websites. Just dashboards. We build, we deliver, clients pay. Easy."

We were excited. The kind of excited where you skip past every red flag because the dream feels too good to question. We had some concerns — no template library, no portfolio, no clients — but we talked ourselves through all of it.

"We'll scrape paid templates from Envato, edit them, deliver. Simple."

Within days we had bought hosting, a domain, and an Envato Elements subscription. The website went live. We gave ourselves titles — CEO, CTO, CSO, Founder — and sat back waiting for orders to roll in.

They did not roll in.

I know. Shocking.

The First (and Last) Client

A few weeks passed. I put up a WhatsApp status about our services. An old friend messaged me almost immediately.

"Bhai, I have a client who needs a dashboard."

We were so ready for this. We'd read about Agile methodologies. We asked for a requirements document like professionals. The friend said the client was non-technical, offered a call instead. We said sure.

Then came the first warning sign, delivered casually: "By the way, this client has been messed around by the previous dev team for a month. Half the team disappeared. Oh, and the client doesn't know."

We should have walked away. We didn't. Old friend, old loyalty. We said we'd handle it.

The brief was simple: a static dashboard with some ChartJS graphs. Student client, tight budget. We quoted fairly, sent a proper proposal via email, got approval, and started.

Scope Creep, Meet Chaos

What followed was a masterclass in everything that can go wrong on a project.

Changes came. Then more changes. Then a WhatsApp group appeared with the client sending voice messages. Budget got revised upward, client said yes every time. We kept building. I was handling the mailing, the project management, the development — basically everything.

When two dashboards in Next.js were finally ready, the client looked at them and said: "The design doesn't match Amazon Seller Central."

I'm a UI guy. Unfortunately. So I matched it. Client was happy. For about three days.

Then our developer got sick. Source code was on his local machine. No repo. Four days of radio silence. My other friend and I kept the project alive by literally changing our names in communications so the client wouldn't notice the team had half-collapsed. I'm laughing writing this, but it was not funny at the time.

When the developer came back, there was a misunderstanding, then an argument, then an uneasy truce because the project wasn't done yet.

The Middleman Problem

Here's the part that still gets me.

All this time, our old friend — the middleman — was relaying messages between us and the client. The client would tell him about new features. We'd send updated quotes and approval documents directly to the client. The client was not reading our emails. He was just telling the middleman what he wanted and assuming it was included.

Nobody caught this until the very end.

When we finally connected all the dots in a proper meeting, we realized the client had no idea what was in our quotes. He thought everything he'd asked for verbally was already covered. We'd been billing for additions he didn't know existed.

To protect the old friendship, we absorbed it. Took the blame. Moved on.

The final invoice was supposed to be $53.78. The client had already paid $35.86. Then, because one advanced feature couldn't be implemented, he said he'd only pay $25.10.

We agreed. Just to close it out. Just to be done.

What Came After

The project ended. And so did the company.

My friends blamed me — it was my reference, my contact, therefore my fault. That hurt more than the $25. I felt like I was the only one who understood what had actually gone wrong, and no one was interested in hearing it.

We went our separate ways.

What I Actually Learned

Not "don't start a startup." Startups are fine. The lesson was more specific than that:

Don't build a company with friends before figuring out who does what. Titles are not roles. CEO doesn't mean anything if there's no sales process, no accountability, no structure underneath it.

Sales comes first. Every student developer I know — myself included, back then — thinks the product is the hard part. It isn't. Getting clients, managing them, scoping projects clearly, following up — that's the hard part. Hire for that first. Everything else can scale later.

Document everything. In writing. Acknowledged by the client. Voice messages in a WhatsApp group are not a contract. A middleman's word is not a contract. If the client didn't read the email, that's a process failure, not just bad luck.

A bad project start doesn't get better with effort. We poured ourselves into that project hoping quality would fix the chaos underneath. It didn't. Sometimes the right move is to stop early.

I'm sharing this because I see a lot of junior developers romanticize the "startup with friends" idea. Sometimes it works beautifully. Sometimes you end up renaming yourself in email threads to hide the fact that your team has fallen apart.

Both outcomes are possible. Just go in with your eyes open.

This is part of an ongoing series where I write about building things — the wins, the disasters, and everything in between.

Maybe this is how Open-Source apps are born... 🚀

Ch. Abdul Wahab — Fri, 17 Apr 2026 02:17:36 +0000

It started with a simple question from a friend.

"Bro, is there no proper tool for QA testing? Like something with a UI?"

I paused. I knew about Pytest. Most people do. But then it hit me — you still have to write code to use it. You just wrote a whole app, and now you have to write more code to test the code you just wrote. That felt wrong.

So I said, "Let me look into it." And then — the way these things always go — I just... started building.

The Stack Graveyard (Before We Found the Right One)

I'm not going to pretend the journey was smooth. It wasn't.

Tkinter was the first attempt. It worked, but it felt like showing up to a product demo in a 2003 Dell laptop. Not the vibe.

PyQt was next. The UI was actually decent. But the moment I tried to package it into an installer for delivery, everything fell apart. The engine wasn't being bundled correctly — users were getting a pretty GUI that did absolutely nothing. A software shell with no soul.

Finally landed on Electron + React + Python. This combo clicked. Electron handled the desktop shell, React gave me the UI flexibility I wanted, and Python stayed in the back doing what Python does best — the actual heavy lifting.

What Tron Actually Does

The core idea was simple: 50 pre-built tests, zero extra code required.

When you install Tron, it automatically sets up a conftest file and all the necessary dependencies in the background. You don't configure anything. You don't write anything. You open the app, paste your URL, pick your tests, and hit run.

That's it.

And when the tests finish, you get a proper structured report — not a terminal dump that you have to decipher, an actual readable report you can share.

I called the backend the Tron Engine. Felt right.

Solo Dev Life at a "Company"

Here's the honest part: Systemset Co. is mostly just me.

I give my projects a company name because it helps me take them seriously — it's a mindset thing. But the reality is, I'm one person wearing every hat. Backend, frontend, packaging, documentation, landing page design, Mac builds, Windows builds — all of it.

Getting the Windows installer working was one thing. Then I thought, let me also set it up for Mac, and spent the next however-many hours wrestling with .dmg packaging on top of everything else.

It's a lot. But it's also kind of the best feeling when it actually works.

The Landing Page

I didn't want the landing page to look like it was spit out by an AI in 30 seconds. That meant doing it properly.

Built it in React, and leaned heavily on Aceternity UI, Cult UI, and React Bits for the component design. These libraries genuinely saved me weeks of work. If you haven't explored them yet and you're building landing pages solo — please do.

For the feedback form, I used Formspree. No backend, no database, just a working contact form with captcha that actually sends me emails. Sometimes the boring solution is the right one.

The One Thing I'm Still Stuck On

Code signing.

If you've shipped a desktop app independently, you know the pain. Without a proper certificate, Windows throws a "Unknown Publisher" warning and Mac Gatekeeper gets dramatic about it. The user experience takes a hit before they've even opened the app.

DigiCert and similar services are expensive — we're talking hundreds of dollars per year, which isn't realistic right now for an independent project. I'm looking into alternatives. If anyone has gone through this and found a reasonable path forward, I'd genuinely love to hear it in the comments.

Where Things Stand

Tron is out. People can use it. I don't know yet how many will, or what they'll think of it.

But I built it because the tool I wanted didn't exist. And if even a few other developers find it useful — people who just want to run meaningful tests without setting up a whole testing framework from scratch — then it was worth it.

Check it out: Tron

Feedback welcome. Especially the critical kind.

First post here. Go easy on me — but not too easy.