A map before a merge
Architecture sketch, risk log, performance baseline, and a prioritised list of what to fix, keep, or rewrite. No code lands until the shape of the problem is agreed.
Shpetim Haxhiu — Senior Full-Stack Developer & AI Solutions Architect, working from Prishtina, Kosovo with teams across the UK, Sweden, and Kosovo.
I started writing HTML by hand in Prishtina before frameworks existed, on machines where a reload cost you ten seconds of your life. That is probably why performance instincts stuck: I learned early that speed is something you feel, not something you measure in a report nobody reads.
Nineteen years later the tools are unrecognisable — TypeScript, Next.js, Prisma, vector search, streaming LLM responses — but the job is the same. Somebody has a workflow that hurts. My work is to understand it well enough to build software that removes the hurt without creating three new ones.
Most of my career has been spent in the unglamorous middle: taking a half-finished system, working out why it is slow or fragile, shipping the missing 30%, and leaving behind documentation that means I am not needed next quarter.
The AI work arrived the same way — not as a research interest but as a delivery problem. Teams wanted document intelligence, voice handling, and proposal automation that behaved predictably under real volume. That means structured outputs, evaluation runs, cost telemetry, and clear escalation paths. The model is the easy part.
Every vertical brings its own compliance rules, peak patterns, and vocabulary. Knowing them in advance is what turns a six-week discovery into a six-day one.
Quote flows, policy admin, digital sales.
Catalogues, checkout, merchandising ops.
Voice agents, tender intelligence, assistants.
Community ledgers, submissions, reporting.
Adaptive content, quizzes, progress loops.
Concierge voice, booking, guest pages.
Architecture sketch, risk log, performance baseline, and a prioritised list of what to fix, keep, or rewrite. No code lands until the shape of the problem is agreed.
A working slice on a preview deployment that real users can click. Feedback from that demo shapes the next slice — assumptions get killed early and cheaply.
Before-and-after measurements for load time, cost per request, and error rate. If a claim cannot be shown on a chart, it does not go in the report.
Runbooks, recorded walkthroughs, architecture notes, and a codebase another engineer can read cold. Dependency on me is treated as a failure mode.
Prefer to see the receipts first? The projects are documented end to end, with proof points attached.
Send the desired outcome, the users, the current bottleneck, the stack, and the timeline. You'll get a practical senior engineering path for the build — not a brochure.