- Year
- Scope
- My role
Architecture chosen
for the problem
Headless, monolith, microservices, SSR — each of them is the right answer somewhere else. I start from whatever tends to jam up in your industry and pick the tools after that.
Architecture matched to the
problem, not the trend.
Every industry has different bottlenecks. The stack is designed for the real use case — interaction level, scale, budget and growth pace. Below are the proven patterns.
High-interaction apps · recommended for startups
Symfony + React + React Native
For rich, high-interaction products I recommend a headless architecture: one solid Symfony API powers both a React web app and a React Native mobile app in parallel. One business logic, three platforms, one person accountable for all of it — the fastest, most cost-effective path from MVP to scale.
- Shared logic and one API contract for web and mobile
- Web + iOS + Android delivered by one person
- Horizontal scaling, Redis cache and task queues
- Time to MVP measured in weeks, not months
Content & marketing
Sites and portals where SEO and instant loading matter. Static and edge rendering.
E-commerce
Stores and marketplaces with fast checkout, payments and courier integration.
Real-time & SaaS
Live dashboards, multi-tenant and subscriptions. Real-time events and queues.
Enterprise & integrations
Mission-critical systems, microservices and integrations with existing infrastructure.
An industry-tailored approach
I know the specifics and regulations of the sectors these systems are built for.
FinTech
Security, auditability and data isolation. Payments, KYC and regulatory compliance.
E-commerce
Conversion and performance under peak traffic. Fast checkout and logistics integrations.
HealthTech
Medical data privacy, telemedicine and integrations with facility systems.
Logistics
Real-time tracking, route optimisation and carrier integrations.
EdTech
Course platforms, real-time progress and scaling to thousands of users.
Real estate
Listing portals, map search and management panels for agencies.
The performance thresholds I hold to
These are not goals for some later date. Every threshold is checked automatically on deploy, and going over one stops the release.
| Metric | Threshold | Why it matters |
|---|---|---|
| LCP | ≤ 1.8 s | When the main content actually appears. Past 2.5 s, Google treats the page as slow. |
| INP | ≤ 200 ms | How long a tap takes to respond. A sluggish interface is felt long before anyone can describe it. |
| CLS | ≤ 0.05 | Layout shifting while the page loads — the main reason people tap the wrong thing on a phone. |
| TTFB | ≤ 400 ms | Server response time. It feeds into every other metric and into your crawl budget. |
| JavaScript | ≤ 180 kB | Script weight after compression. It decides whether the site works on older phones and weak signal. |
| Lighthouse | ≥ 95 | The combined performance, accessibility and SEO score — you get the report at handover. |
Also worth a look
Got a project in mind?
Describe it in a few sentences — I reply within 24 hours with a free quote and a proposed stack.