Full-Stack & AI Systems Engineer
Collins Madubuilds web platforms
I take a business problem — procurement, approvals, discovery, reporting — turn it into a system, and ship it to production. Web, mobile, backend, and the AI in between.
71 projects, nearly all of them built solo, end to end. Where a build was shared, the role line says what was mine.
In production
- projects built
- 71projects builtacross full-stack, AI, automation and data
- commits, solo
- 321commits, solo~86K LOC on one production platform
- supplier offers scored
- 188ksupplier offers scoredrunning daily for a European distributor
- listings per minute
- 300+listings per minutesustained by a deployed vision pipeline
Selected work
Systems that went into production.
How I work
Four steps, every time, whatever the domain.
The stack changes constantly. The sequence doesn't.
01 · Understand
Sit with the actual workflow
Before a line of code: what arrives, in what format, from whom, and what the person receiving it does with it. Supplier price lists in nine languages. Approval chains that live in someone's head. A spreadsheet that is really a database. This is where most of the value is decided.
- supplier-a@…XLSX · DEread
- supplier-b@…PDF · FRread
- supplier-c@…body text · ITread
- supplier-d@…CSV · PLqueued
02 · Architect
Design the system, not the screens
The data model, the state machine, the scoring rules, and the boundaries between services come first. A normalizer that handles one supplier is a script; one that handles a hundred is an architecture. Screens are the last thing, not the first.
offer
ean · ref · brand · price · currency
supplier
id · terms · reliability
score
rank · delta · margin · confidence
03 · Ship
Put it in production and keep it there
Auth, roles, audit trails, error paths, deploys. Azure AD SSO and Microsoft Graph where the client already lives; Railway, Vercel or Azure Container Apps for the rest. Shipped means real users depending on it on a Monday morning — not a demo branch.
- JWT + Azure AD SSO
- role-based access, audit trail
- CI: ruff · mypy · pytest · eslint
- deployed — Railway + Vercel
04 · Hand over
Leave something someone else can run
Architecture notes, runbooks, SOPs, and — where it matters — a documentation site. The measure of the work is whether it survives without me in the room.
- architecture.mdsystem overview, decisions
- runbook.mddeploys, failures, recovery
- sop-daily.mdwhat the operator does
- docs sitetask guides, annotated
Domains
Where the work actually lands.
Full-Stack Products
End-to-end platforms with auth, RBAC, approval workflows, dashboards, payments and audit trails.
AI Systems
Computer vision, LLM extraction with schema validation, RAG and vector search — wired into decisions, not demos.
Scraping & Data
Stealth scrapers, API reverse-engineering, OCR fallbacks, normalization and dedupe at national scale.
Automation
Microsoft Graph mailbox ingestion, spreadsheet normalization, CRM enrichment, and finance reconciliation.
Mobile Apps
Flutter and React Native, feature-first architecture, connected to production backends and ML services.
ERP & Internal Tools
ERPNext and Odoo evaluation, e-signature and leave portals, IT operations and internal security.
Creative Tooling
Generative art placement, price builders, metadata systems and publishing workflows.
Questions people ask before starting.
What do you charge?
€70 an hour as a baseline, and that covers the whole job — architecture, backend, frontend, deployment and the documentation someone else can run it from. I don't bill those as separate rates. Where a project can be scoped properly up front I would rather quote a fixed price, because that puts the risk of my own underestimate on me instead of on you.
When could you start?
Usually within a week, sometimes the next day. The variable is rarely availability — it is how much research a project needs before I can say anything useful about it. A landing page I can scope in an afternoon; a system that has to read supplier spreadsheets in nine languages takes rather longer before I would be willing to quote it.
How long is a typical engagement?
Most run four to twelve weeks. The two largest have been going for over a year — once a system is something people depend on every morning, there is usually a next thing worth building.
What do you actually build?
Production systems for businesses: procurement and pricing platforms, approval and e-signature workflows, employee portals, AI discovery products, scraping and ETL pipelines, and the dashboards that sit on top of them. Web, mobile, and backend — usually all three on the same project.
Can you take over an existing codebase?
Regularly. Several projects here started as someone else's repository — a web frontend I extended into a full mobile product, an e-commerce build I picked up mid-flight, a marketplace scaffold I forked and rebuilt around a new ML service. Reading unfamiliar code is most of the job.
Do you work solo or as part of a team?
Mostly solo. Almost everything in the archive I designed, built, deployed and documented alone — including projects I inherited part-way and owned from that point on. A few were shared builds where I took the front end and someone else the back, or the reverse; those carry the role that was actually mine and claim nothing beyond it.
Why do some projects have no link or screenshot?
They're client systems. Those entries describe the problem, my contribution and the stack, and identify the client by sector rather than name — a European B2B cosmetics distributor, a capital-investment firm. No source, no screenshots, no data. Happy to go deeper in a conversation.
How much of the AI work is real?
All of it runs. Fine-tuned segmentation models with a tiled-inference scheme, vector search over Milvus, LLM extraction with schema validation and fail-closed handling, a vision pipeline sustaining 300+ listings a minute. Where a model is doing something a rule could do better, I use the rule.
What do I get at the end?
A deployed system, the repository, and documentation written for whoever runs it next: architecture notes, a runbook, and operator SOPs. On one internal product that included a full documentation site with annotated walkthroughs.
You have a process thatshould be a system.
Tell me what arrives, who has to act on it, and where it currently falls over. That conversation is usually enough to scope the build.