APIs and contracts
REST APIs, OpenAPI, DTOs, Problem Details, pagination, 401/403/422/429, versioning, and clear responsibility boundaries.
Project portfolio / PHP Backend / B2B systems
I design PHP backends that connect clean architecture with production readiness.
Solid Apps shows how I think about systems: API contracts, application layers, idempotency, tests, observability, DDD where it helps, and a pragmatic modular monolith before anyone starts multiplying microservices.
- Model
- Sole proprietorship / B2B / remote
- Focus
- PHP 8.3+, APIs, integrations, system design
- Repo
- github.com/matii-dev
The shortest version
Solid Apps is a backend portfolio built around real engineering decisions: status transitions, idempotency, webhook signatures, test strategy, C4/NFR/ADR, and runbooks.
Where to start
Start with ShopFlow, Payment Adapter, Rentals Booking, CLI Data Importer, and URL Shortener. These projects show code, responsibility boundaries, and explicit trade-offs.
Positioning
Not a technology list. A set of problems a backend has to carry.
Integrations and payments
HMAC webhooks, idempotency keys, retries with backoff and jitter, audit logs, refunds, and failure-mode design.
Legacy rescue
SQL audits, EXPLAIN, indexes, refactoring plans, service layers, characterization tests, and gradual PHPStan adoption.
System design
C4, NFR, ADR, capacity estimates, cache invalidation, health checks, runbooks, and modular-monolith vs microservice decisions.
Selected projects
Projects that show how I design backend systems.
Each entry connects the problem, technical decisions, demo scope, and deliberate next steps. This is not a screenshot gallery. It is a map of competence signals.
8 projects visible
P1
ShopFlow E-commerce
Checkout API / order statuses / idempotent payments
An e-commerce project grown in slices: catalog and cart UI, PHP checkout endpoint, order admin panel,
payment audit trail, and explicit status transitions new -> paid -> shipped and new -> cancelled.
- Decisions: application services, repository ports, admin token,
Idempotency-Key. - Demo: checkout,
pay-latest-order.php, status-change API, CI for the order module.
P1
Payment Adapter
Ports & Adapters / Money VO / webhook HMAC
A payment module built around a shared PaymentGatewayInterface, Stripe/PayPal adapters,
a Money value object, request/result DTOs, idempotency, and webhook auditing.
- Decisions: service layer, normalized
PaymentResult, HMAC signature verification. - Demo: charge, refund, idempotency replay, webhook verification, ShopFlow checkout example.
P1
URL Shortener
Base62 / idempotent shortening / click stats
A small but complete backend: URL validation, Base62, idempotent shortening, custom aliases, file repositories, click tracking, and shared logic for web and CLI.
- Decisions: service layer, URL reverse lookup, alias validation, and one consistent web/CLI entrypoint.
- Demo: encode/decode, alias, click stats, idempotency demo in CI.
P1
CLI Data Importer
ETL / batch processing / dry-run discipline
A CSV/JSON/XML importer that shows practical backend work outside HTTP: record validation,
--dry-run, --limit, --continue-on-error, batch IDs,
duplicate detection, and a JSON report for automation.
- Decisions: reader interfaces, report object, batch metadata, and import as a service layer.
- Demo: CSV/JSON/XML import, duplicate SKU, JSON report, all demos in CI.
P1
Rentals Booking
DDD tactical / aggregate lifecycle / domain events
A booking module showing DDD in PHP: aggregate, Value Objects, command/handler, repositories, PDO transactions, domain events, outbox, worker, and idempotent side effects.
- Decisions: booking lifecycle in the domain, events as business facts, outbox before a broker.
- Demo:
created -> confirmed -> checked_in -> completed, cancellation flow, and outbox worker.
P2
Three-Microservice Distributed System
HTTP + RabbitMQ / Docker Compose / health endpoints
A demonstration of three independent PHP services: user-service, order-service,
and notification-service. It shows service boundaries, synchronous HTTP, and asynchronous events through RabbitMQ.
- Decisions: separate Composer dependency graphs, worker as a different process type than an HTTP API.
- Demo:
POST /orders, user lookup,order_createdpublishing, notification consumer.
P2
Solid Blog Engine
Custom MVC / attribute routing / admin security
A minimalist PHP blog engine: front controller, attribute-based routing, request/response objects, JSON persistence, search, pagination, admin auth, CSRF, and flash messages.
- Decisions: simple MVC without a framework, PSR-4, session-backed security, slug service.
- Demo: admin login/logout, post creation, CSRF flow, CI for auth and CSRF demos.
P2
Vue 3 Admin Panel + Headless React SPA
Admin UI / SPA auth states / API-oriented frontend
Two frontend projects showing practical backend-facing UI: a Vue 3 CRUD panel and a React SPA focused on sessions, auth states, routing, and a backend contract.
- Decisions: SFC components, Vite, loading/error states, validation, and productive CRUD.
- Demo: mock API, forms, filtering, CI build, and session flows.
No project matches the selected filters. Change the query or category.
Stack and standards
Technologies grouped by responsibility, not popularity.
Runtime and framework
PHP 8.3 / 8.4 / 8.5, Symfony, Laravel, Composer, PSR-4, service container, Scheduler, Messenger.
Data and flows
Doctrine, Eloquent, PDO, MySQL, PostgreSQL, Redis, RabbitMQ, outbox awareness, CSV/JSON imports.
API and auth
REST, OpenAPI, JWT, OAuth 2.0, OIDC, RBAC/ACL, HttpOnly cookies, webhook signature verification.
Quality
PHPUnit, Pest, PHPStan, Psalm, php-cs-fixer, contract tests, smoke tests, test strategy matrix.
Production
Docker, Docker Compose, Nginx, PHP-FPM, GitHub Actions, Sentry, OpenTelemetry, structured logs.
Architecture
Modular monolith, tactical DDD, Clean/Hexagonal, C4, NFR, ADR, runbooks, and failure-mode analysis.
Technical decisions
Where backend projects usually win, or quietly create debt.
API contract
How do you design an endpoint without hiding the contract in the controller?
Start with OpenAPI, request/response DTOs, an explicit error format, and 401/403/422/429 statuses. Only then make the controller a thin layer delegating to an application service.
- What does 422 validation and error mapping look like?
- Where do retry and idempotency keys live?
- How do you keep frontend and backend aligned without guessing?
Working process
Entering a project without chaos, delivering without guesswork.
I work so that every iteration leaves more than code behind: decisions, contracts, tests, and the context the team needs to maintain the system.
Principle:
risk and responsibility boundaries first, implementation second.
-
01
Problem discovery
I identify what actually hurts: an endpoint, integration, SQL, checkout, queue, legacy flow, or missing ownership.
Output: risk map, first-iteration scope, out of scope. -
02
Contract and technical plan
I define module boundaries, DTOs, HTTP statuses, idempotency, retry policy, and architecture decisions.
Output: OpenAPI / ADR / mini C4 / test strategy. -
03
Implementation with quality criteria
Small changes, readable commits, tests, PHPStan/Psalm, php-cs-fixer, and review of the highest-risk areas.
Output: working flow, tests, trade-off notes. -
04
Delivery and context handoff
I close the README, smoke tests, health endpoints, runbook, deployment notes, and the next-risk list.
Output: review-ready code and documentation for the team.
Quality gate before calling work done
- does the flow have a test or a clear demo scenario?
- does the error have a predictable status and message?
- is the retry, webhook, or job idempotent?
- will the next person understand the decisions from README/ADR?
Artifacts
What is worth seeing beyond the code itself.
The portfolio is designed to show not only PHP syntax, but mature decision-making: how the system is described, where boundaries live, what is out of scope, and which risks were named.
README
goal, setup, demo flow, trade-offs
ADR
why modular monolith, where cache belongs, when a queue is justified
C4 / NFR
system boundaries, non-functional requirements, failure modes
Runbook
health endpoints, smoke tests, deployment notes, rollback awareness
Let’s talk technically.
The best starting format: pick one project or one problem in your system, and I will walk through the decisions, trade-offs, and first risks worth closing.
GitHub matii-dev
kontakt@solidapps.pl
NDA on request · VAT invoice · remote work · B2B · retainer or project