Full stack development
End-to-end web applications built on Spring Boot and React — and a steady hand for tracking down bugs in the ones you already have.
The largest system I have built, and the one I am working on now. Exelerating is an investment intelligence platform: institutional investors, the people inside them, the mandates they run and the connections between them — searchable, monitored over time, and replacing a legacy estate that answered none of those questions well.
The technical problem
- The questions are about relationships, not rows. “Which pension funds changed fiduciary manager last year, and who sits on both sides?” is a graph traversal wearing a report's clothing. A schema optimised for listing entities cannot answer it; the data model had to make entities, people, mandates and their edges first-class from the start.
- Two products share one codebase. A client-facing platform and an internal CMS have different users, different permissions and different rules, but the same domain underneath. Left unmanaged, that is exactly how an application turns into a tangle where an admin change breaks a client page.
- A live legacy system to migrate from. Years of data in MSSQL had to move to Postgres without inventing history or losing it, while the old system was still in use — so the migration had to be repeatable and reconcilable, not a one-shot import.
- Data-heavy pages must still feel fast. Tables of thousands of rows, a force-directed network graph and cross-entity search are each capable of making a page unusable on their own.
How I solved it
- Enforced architecture: layered clean architecture over the Next.js App Router — app → presentation → application → infrastructure → core, with dependencies pointing inward and the boundaries enforced in the lint configuration. The rule fails a build rather than relying on anyone remembering it, which is what keeps two products in one codebase from bleeding into each other.
- Security at the database, not the route: Supabase Postgres with row-level security throughout, so access rules live where the data does and an admin surface and a client surface cannot accidentally share a door.
- A schema built to evolve: a five-file baseline plus incremental migrations, and typed access from the application layer so a schema change surfaces as a compile error rather than a runtime surprise.
- Validation at the boundaries: Zod schemas where data enters, TanStack Query for server-state and caching, TanStack Table for the data grids — so components render state they can trust.
- Migration tooling: scripts that move and reconcile MSSQL data into Supabase and can be re-run, which is what makes cutting over from a live legacy system survivable.
- A deliberate rendering strategy: a documented per-route decision on static, dynamic and client rendering with a data-loading budget, because on a data-heavy product that is an architectural choice, not a performance afterthought.
- Network graph: a force-directed view over entities and people, for the relationship questions a table genuinely cannot express.
- Mobile: a Capacitor Android shell around the web app, so one codebase ships to a device.
Why it matters
This is the project where the architecture has to hold under real weight: a thousand-plus commits, a schema that keeps moving, two products with different rules, and a legacy system being retired underneath it. Most of the engineering judgement I would bring to a team is visible here.
Stack
Next.js 16 · TypeScript · Supabase (Postgres, Auth, RLS) · TanStack Query · TanStack Table · Zod · Tailwind CSS · d3-force · Capacitor · Vitest · Vercel
The client sold luxury watches without a website. Every enquiry ran through WhatsApp: a customer asked for a Rolex, the shop scrolled its own photo library, and sent a burst of images back. There was no way to browse, no way to compare two pieces, no way to filter by brand or size, and no link to send anyone. YR Luxury is the web app I built to replace that conversation with a catalogue — 7,000+ watches across 45+ brands that a customer can explore on their own, in Dutch or English, and only reach for WhatsApp once they know exactly what they want.
The technical problem
Three constraints shaped every decision.
- Scale on the client. Seven thousand products with images is not a list you paginate on a server you do not have. The whole catalogue had to stay searchable and filterable in the browser without the page stalling on every keystroke.
- Unstructured source data. Brand, model, size and variant were not fields — they were free text inside product titles, written inconsistently over years. Filtering by brand is trivial once you have a brand column; the work was deriving one that could be trusted.
- No sales team on the site. The shop's expertise lives in a chat. The site had to narrow thousands of options down to the handful worth asking about, then hand the customer to WhatsApp with the context already attached.
How I solved it
- Brand normalisation: a keyword-matching resolver that reads a messy product title and returns a canonical brand across 40+ names, tolerating abbreviations, spacing variants and misspellings. Everything downstream — filters, brand pages, breadcrumbs — depends on it, so it runs once at ingest rather than per render.
- Faceted filtering: brand, size, men's/women's, diamonds and quality, combined freely and evaluated client-side against a normalised index, with search debounced so typing never blocks the grid. Paging keeps the DOM small while the filters still see the whole catalogue.
- A real page per watch: its own URL, image gallery, specifications, shipping and payment options and breadcrumbs — so a product can be linked, shared and indexed, which is precisely what a photo in a chat can never be.
- Bilingual routing: Dutch and English across the interface and the product routes, because the shop sells to both markets.
- Favourites: a shortlist the customer assembles while browsing and sends over as one message instead of thirty screenshots.
- WhatsApp hand-off: deep links that pre-fill the product, so the enquiry arrives with the watch already identified and the conversation starts at the price rather than at “which one?”
- Admin dashboard: the owner manages the catalogue — status, source, live counts — through an interface rather than through Firestore.
What it changed
The shop stopped being a photo album behind a phone number. Customers self-serve through 7,000 products and arrive in the chat already decided, which turns WhatsApp from a browsing tool into a closing tool.
Stack
React · Vite · Tailwind CSS · Firebase / Firestore · Firebase Hosting · React Router · i18n (NL / EN)
Computerredder does computer repair at people's homes across Zuid-Holland. The customers are older, not technical, and they find help the same way every time: they search a town name plus a problem. That makes the whole business a search problem — and it makes the owner's ability to change a price without phoning a developer a hard requirement, not a nice-to-have.
The technical problem
- Local search needs pages, not keywords. Ranking for “computerhulp aan huis Dordrecht” means having a page about exactly that — and the same for every town and every service, which multiplies into dozens of combinations that no one is going to write or maintain by hand.
- Content that changes must not need a deploy. Rates, phone number, WhatsApp and availability appear on nearly every page. If editing them means a developer, they go stale; if they go stale, the site starts lying to customers.
- Speed and reachability on a small budget. The audience is on modest devices and sometimes bad connections, and the business should not carry a monthly bill for a database it barely uses.
How I solved it
- Programmatic pages: Next.js 16 App Router with TypeScript, statically generating around 60 pages from the service and location matrix — one real, indexable page per town and per service, each with its own metadata and structured data, all from one template.
- Self-service admin: a password-protected portal where the owner edits rates, contact details and availability. Saving revalidates the affected static pages, so a single edit propagates across the whole site within seconds and stays statically served afterwards.
- Right-sized storage: a JSON file in development, Redis in production. The site has one settings document, not a relational model, so it does not carry a database it would never use.
- Contact without an inbox to harvest: a form over Resend instead of a published email address, defended with a honeypot and a timing check, working with JavaScript disabled, and storing nothing — the message leaves as email.
- Identity, not a template: cream, pine green and amber with Fraunces headings and a lifebuoy mark, so it reads as a local business a neighbour would call.
The result
A statically rendered site that competes on local search across a whole province, and that its owner maintains alone — no deploys, no developer, no monthly platform bill.
Stack
Next.js 16 (App Router) · TypeScript · Tailwind CSS 4 · Redis / Upstash · Resend · Vitest · Vercel
Alshammari Faraa needed an order-management back office that matched how their team actually works rather than how the data is shaped. I built the Alshammari Faraa orders dashboard end to end: orders arrive on their own from Instagram, the interface is right-to-left throughout, and it is quick enough to use all day.
The brief
Replace slow, manual order handling with a dashboard the team can move through fast: bulk actions, filtering, invoice printing and Excel export, usable on a phone as well as a desk, with admin and employee roles kept apart. Most orders came in through Instagram direct messages and were being copied out by hand, so capturing those automatically was part of the job.
How I built it
- Frontend: React 19 with Vite and TailwindCSS, with full RTL support rather than a mirrored afterthought.
- Order capture: a ManyChat automation on Instagram that handles the customer conversation in DMs and posts the finished order straight into the Apps Script API. An order placed in a chat shows up in the dashboard without anyone retyping it.
- API: Google Apps Script serving an orders API — CRUD, bulk operations, a status lifecycle and statistics, and the endpoint the Instagram bot writes into.
- Data: Google Sheets as the datastore, reached through those Apps Script endpoints, so the team keeps a familiar view of their own data.
- Deployment: Firebase Hosting with auto-deploy from GitHub Actions.
- Interface: a clear information hierarchy with status badges, toasts and accessibility-friendly interactions.
The result
Alshammari Faraa now run daily operations from one place rather than occasional admin: orders captured straight from Instagram chats, role-based access, bulk work in a few clicks, and a deployment path where changes ship automatically.
Stack
React · React Router · Vite · TailwindCSS · Google Apps Script · Google Sheets API · ManyChat · Instagram automation · Firebase Hosting · GitHub Actions CI/CD · RTL UX
Screenshots
Digitale Zahnarztpraxis Salzburg, a dental practice in Salzburg, Austria, needed a website that reads as clinical and credible without feeling cold — and that works as well on a phone in the waiting room as on a desktop. I built the Digitale Zahnarztpraxis Salzburg site end to end as a freelance engagement.
The brief
Present the practice as modern and trustworthy, put patient information within easy reach on any device, and keep the whole thing fast. Accessibility, performance and the mobile experience were the priorities from the first conversation, not an afterthought.
How I built it
- Frontend: a responsive React.js front end, built to hold up from desktop down to a phone screen.
- Design: clinical requirements translated into a clean interface with clear visual hierarchy and intuitive navigation, so patients find what they came for without hunting for it.
- Hosting and data: Firebase for secure, scalable hosting and real-time data management, keeping latency low for local visitors.
- Deployment: a GitHub Actions CI/CD pipeline, so every change runs through automated checks before it reaches the live site.
The result
A bespoke platform Digitale Zahnarztpraxis Salzburg can put in front of patients with confidence: fast, accessible across devices, and safe to change — updates ship through the pipeline rather than by hand.
Stack
React.js · Modern CSS / Tailwind · Firebase (Hosting & Analytics) · GitHub Actions CI/CD · Responsive UX · Frontend architecture
Screenshots
Amy is a freelance graphic designer whose work needed a home that looked as considered as the work itself. I built her a responsive portfolio site from scratch.
The brief
Put the portfolio front and centre, make it easy to get from the work to the services and the contact details, and have it hold together on any screen a prospective client might open it on.
How I built it
- Design: a visually clean layout with a clear structure, so the graphic design work is what draws the eye rather than the interface around it.
- Navigation: a straightforward path between the portfolio, the about page, the services and how to get in touch.
- Responsiveness: Bootstrap's grid to adapt cleanly from desktop through tablet to mobile.
Stack
ReactJS · Bootstrap · CSS
Code
Screenshot
An e-commerce front end for Mangata & Gallo, a jewellery retailer. Product photography does the selling in this category, so the interface had to stay out of its way while still feeling like the brand.
The brief
Build a storefront that carries the brand consistently, presents the pieces well, and performs the same on a phone as on a desktop.
How I built it
- Interface: ReactJS for a dynamic browsing experience, with interactive elements that keep customers moving through the catalogue.
- Layout: Bootstrap for a fully responsive grid across desktop, tablet and mobile.
- Styling: clean, maintainable CSS to keep the design visually consistent with the brand rather than fighting it.
Stack
ReactJS · Bootstrap · CSS · JavaScript
Code
Screenshot
