Open for new projects
Ridwan Yahya, web developer. I help organizations turn messy processes (scattered spreadsheets, manual recaps, data nobody trusts) into systems that are clean, honest, and used by the team every day.
The live sites belong to clients and hold internal data, so for privacy they are not linked here. Instead, each project has an interactive demo with sample data that shows the exact same system.
The design team received thousands of requests a year (banners, video, social content) from branches across the country. I built a realtime kanban system: every request gets a brief, an asset archive, comments, notifications, and clear assignment, replacing coordination over chat that kept losing track of who did what.
Every important action is logged through a database-level audit trail, so the history can't be faked or quietly deleted.
±2,000 orders/year · multi-branch, national scaledemo@ridwamovic.uk
·
ginhez-Danxed-vabwe6
Meetings produce decisions, and the decisions evaporate. This turns minutes into tasks that have an owner and a deadline. They can be pasted straight from the meeting document, then dragged across a board until they are done.
Only the owner or an admin may change a status, and every change lands in an audit trail that cannot be edited. The dashboard measures how long work actually stayed in progress, not just how much of it finished.
Board & list · deadline alerts · audit trailHundreds of physical donation boxes spread across mosques, shops, and small stores. This mobile-first app tracks location, pickup schedule, and collected amount per box, plus automatic alerts for boxes overdue for pickup.
Reports export straight to Excel/PDF, and field staff only need a phone.
4 regions · mobile-first · Excel/PDF exportA website for a researcher: journal publications with correct academic metadata (indexed on Google Scholar), articles, and a profile page. All of it managed by the client through an admin panel, no code required.
Technical SEO was taken seriously: sitemap, canonical tags, and a structure built to make the writing easy to find on Google.
Custom domain · admin CMS · technical SEOThe Meta pixel tends to claim more than what actually came in. This app ingests ad report files + donation records, then computes two numbers side by side: ROAS as reported by Meta, and ROAS from donations that actually landed.
Budget decisions get made on real money, not platform claims. Reports are stored server-side so leadership can pull them up from their own device.
Dual ROAS · fundraising campaign analyticsAd accounts were scattered across many Business Managers, impossible to monitor one by one. This dashboard pulls data straight from the Meta API on every load, with no database and no manual recap. It flags ads that start "fatiguing" before performance actually drops.
The team gets time to prep replacement creative instead of scrambling after the numbers already fell.
26+ ad accounts · live data on every loadThe first time I touched code was 2011: learning from other people's code, taking Blogger templates and widgets apart and putting them back together. It stopped there. Building a whole application was still well out of reach.
What changed this year is the tooling. AI shortened the distance between understanding a problem and having a system that runs, short enough for me to cross on my own. What can't be handed to AI is the part that decides everything: choosing the architecture, sitting with clients to understand the actual problem, and making sure what gets built actually gets used. Not shipped and forgotten.
All six systems above came out of that, and every one of them is in daily use.
What's on screen has to hold up. When there are two versions of the truth (platform claims vs. real money), I show both. Not just the one that looks good.
The people using my systems aren't IT staff. If it needs a long training session, the design failed. A good system should feel obvious the first time you open it.
Access control, backups, and audit trails are built in from day one, not patched in after something goes wrong. The specifics are below.
Every table carries rules about who may read and change what, enforced by the database itself. If someone calls the data directly without going through the app, those rules still hold. It is not a matter of hiding buttons.
The database writes it, not the application, so it cannot be bypassed. Who did it comes from the login session, not from submitted data that could be forged.
In two of these systems the tests run on their own every time the code changes, including walking through the whole flow in a real browser the way a user would.
Backups are set up to fit each client's needs and budget. They are kept for 90 days, and on the system whose data changes most often, every backup is restored as a test to prove it actually works. A backup that has never been tried may not work when it is needed. Code changes are also scanned automatically for keys or passwords committed by accident.
Every change is made on a separate copy, opened on a preview address, shown to work, and only then promoted. Database changes are tested first inside a transaction that is deliberately rolled back: tried against real data, leaving nothing behind.
Want to see these roles as a picture? Visit the Agent Office →
Contact
Tell me the problem: manual recaps, scattered data, or reports nobody trusts. I'll help turn it into a system that holds up.