Services
Custom web applications
A business system that other people depend on: accounts, roles, records, money, and the boring middle that makes it hold up for years. Built in Laravel on PostgreSQL, server-rendered, and handed over with the documentation to run it.
- Stack
- Laravel, PHP 8.3, PostgreSQL, Blade, Alpine.js, Vite, Reverb, PHPUnit
- Terms
- Scope call, paid discovery, written plan, fixed-bid milestones
How Fopull approaches it
Most custom web work is a database with a job to do. Somebody needs to record something, somebody else needs to act on it, and a third person needs to be sure the first two cannot see what they should not. The interesting decisions are in the schema, the permissions model and the migrations, not in the framework, and those are the parts that are expensive to get wrong later.
The default stack is Laravel on PostgreSQL with Blade views, because a server-rendered page is faster to build, faster to load and easier for the next engineer to change than a single-page app wired to an API. A JavaScript framework appears when the product genuinely needs one: a live board, a drag-and-drop editor, a game. Alpine.js covers most interactivity short of that.
Authentication and authorization are done properly the first time: sessions, CSRF, password reset flows that survive an audit, two-factor where the data warrants it, and a role and permission model that holds up when there are tenants inside tenants. Every migration is verified up and down on a throwaway database before it touches yours, and a backup is taken and checked before it runs.
What you get at the end is the source, the infrastructure it runs on, a test suite that means something, and a runbook. The point of the runbook is that the system does not depend on Fopull to keep running.
Worked example: fopull.com itself
This site is a Laravel application on PostgreSQL 16, served by Apache and PHP-FPM behind a Cloudflare tunnel, with Laravel Reverb for websockets. One account covers the company site, the Foverse community platform, the Foduel card game and the Floptle developer portal, on a single users table with capability grants rather than a second identity system.
It carries about 1,300 automated tests, including guards that grep the templates for the mistakes that have actually shipped here: a hand-written price that drifted from the plan it described, a Blade directive written against a word so it never compiled, a scheduled command whose argument was silently passed as an option. Each guard exists because of a specific day in the ops log.
The deploy is a script that refuses a dirty tree, dumps the database first, runs migrations, rebuilds the caches and reloads the services in one breath, because the one time those steps ran separately the site was down for five minutes.
More of this, dated and with the numbers, in the engineering log.
Questions people ask
- Do you build single-page apps?
- When the product needs one. Most business systems do not, and a server-rendered Laravel app is faster to build, faster to load and easier to maintain. React or Vue is used where there is a genuinely app-like screen.
- Can you take over an existing Laravel codebase?
- Yes. The first step is a written assessment of what is dangerous and what is fine, then a plan that fixes the dangerous parts and leaves the rest alone.
- What do you hand over?
- Source, infrastructure, tests, and a runbook covering deploys, backups, restores and the failure modes seen during the build. Enough for another engineer to run it without Fopull.
How an engagement goes
A scope call
Thirty minutes on the problem and the constraints.
A written plan
Short paid discovery, then a document you can take anywhere.
Built in milestones
Fixed-bid where the scope is clear, hourly where it cannot be.
Handed over with a runbook
Or run for you under a retainer.