shipping/JOG — 03:41 GMT+7/48.3 °C CPU/v 07.0 · build 2026.05.12
lat −7.7956 · lon 110.3695/ntwk · online/open for projects
back to notesnotes2026laravel-scaffolding-15-apps
[ essay no. 21 ]processjune 10, 20266 min1,168 wordsrevision 1live

15 apps · 4 months

Imajiku selected me from 165+ candidates for a React Native role and pivoted me to full-stack web inside week three. The reusable Laravel + Alpine + GraphQL scaffolding that survived all 15 builds.

d
devrangga hazza mahiswaracreative engineer · jogja, id
share on 𝕏

15 apps · 4 months

15+apps to production
165+candidates · 1 hired
~30%delivery cycle cut
4 mosep → dec 2024

The Imajiku interview was for a React Native role. Two weeks into the contract, the engineering lead asked if I'd shipped Laravel before. Two weeks after that I was the primary full-stack developer on a queue of client web apps that needed to ship faster than the team could staff for. The pivot took four days; the cadence it set ran for the next four months.

Fifteen production apps in four months works out to roughly one shipped every eight working days. That tempo is impossible without scaffolding. This post is the scaffold I built, the parts that held across all 15, and the cost paid for the velocity.

01

what imajiku ships

Imajiku is an Indonesian agency. The pipeline is mostly Indonesian SMEs and government-adjacent contracts. The apps look the same from a distance — internal tools, customer-facing portals, admin panels, occasional consumer-facing applications. Different domains, similar shapes.

The cadence was aggressive for a reason: a small team, a deep pipeline, deadlines committed in sales calls before engineering scoped. The agency reality. The choice was either ship faster than feels prudent or miss deadlines and lose clients. The team chose the first.

02

the scaffolding

The reusable shape that emerged by week six and held through week sixteen:

Auth and user management. Pre-built Laravel module with: email + password, role-based permissions (admin, user, custom), Indonesian phone-number validation, password reset, optional 2FA. Dropped into every project without modification 90% of the time.

Admin panel template. Filament-based, with: CRUD scaffolding for any Eloquent model in two lines, soft-delete enabled by default, audit log built in, dashboard widgets ready to clone, role-aware menu. Saved roughly 3 days per project.

Form-handling pattern. A consistent way to handle multi-step forms — validation, draft state, auto-save, file uploads. Three weeks of iteration on project 1 turned into a one-day drop-in on project 5.

Alpine.js component library. Small set of interactive widgets — modals, dropdowns, tabs, accordions, toast notifications. Lighter than Vue or React for these projects, faster to integrate with Blade templates than a full SPA approach.

GraphQL endpoint pattern. For the projects that needed an API surface: a Lighthouse-based setup with auto-generated schema from Eloquent models, query complexity limits, depth limits, basic rate limiting. About 60% of projects used GraphQL; the others used regular Laravel API routes.

03

what cut 30% of delivery time

The specific things that moved the number from "behind schedule" to "ahead of schedule" most reliably:

The auth + admin combo. Almost every project needed both. Having a tested, hardened version available as a starting point compressed weeks 1-2 of a typical project into about 3 days.

Form-handling pattern. Multi-step forms with validation, drafts, and file uploads are long-tail-bug-heavy. The standardized pattern saved roughly a day per project that would have gone to fixing field-validation edge cases.

The deployment script. I wrote a single deploy script (Forge-compatible) that handled migrations, asset compilation, queue restarts, cache warming. Used identically on every project. The deploy was reliable enough that the deploy was no longer the risk on launch day.

The "stop building" rule. When a feature was 70% built and the deadline was visible, I stopped adding features and started adding polish. Counter-intuitive but reliable. Most projects fail to ship because they're 80% done on too many features rather than 100% done on fewer.

04

the cost — the parts that came back to bite

The 30% velocity gain wasn't free. Three places it cost me:

Architectural homogeneity. Every project looks the same under the hood. That's the goal — but it means projects that should have diverged from the template (different scale requirements, different team handoff needs, different compliance requirements) didn't. Two projects I shipped using the standard scaffolding would have been better with custom architectures. The agency model didn't have the budget for that, so the standard scaffold shipped anyway.

Tech debt accumulated in the scaffold itself. The scaffold got better over the four months, but the projects that shipped first didn't benefit from improvements made later. If you'd open project 1 and project 15 today, project 15 has cleaner code. Project 1 is now technically owned by Imajiku and runs on the older patterns; nobody is going back to upgrade it.

Skill compression. Four months of high-cadence shipping is great for tactical execution and bad for skill depth. I wrote a lot of Laravel. I learned less about the frontier of Laravel — new packages, new ecosystem patterns — because there was no time to research outside the immediate pipeline. The agency cadence is a velocity machine and an exploration tax.

05

when this works, when it doesn't

The 4-month sprint worked for me because:

  • I'd already shipped at least 5 Laravel apps before joining
  • The pipeline was structurally similar projects, allowing scaffold reuse
  • The team had a deployment story I didn't have to invent
  • I was being paid agency rates, not freelance rates, so the time-per-project math worked

It wouldn't work for someone who is:

  • Learning Laravel from scratch (the cadence eats learning time)
  • Independent freelancer pricing on hourly (the structural overhead doesn't amortize)
  • Shipping structurally different projects (the scaffold doesn't reuse)
  • Without a tested deployment story (deploy risk swamps build velocity)

The agency context is a specific instrument. The same tempo applied to a different setup would have broken faster.

06

what i'd take into the next agency role

The single most transferable instinct from the four months: shipping cadence > technical elegance, at the agency tier. Most engineers default to over-engineering each project. The right move at the agency tier is over-engineering the scaffold once, then under-engineering each project on top of it.

The single most transferable artifact: the deploy script. Every freelance project I've taken since has gotten a version of it inside the first day. The cost is half a day; the savings compound across every push for the project's life.

The single most uncomfortable lesson: every shortcut you take is a debt someone else will pay. The agency was OK with that trade-off; I was an early-career engineer learning velocity. A more mature version of me, in 2025-2026, ships fewer projects per quarter and writes better code in each. The 15-apps-in-4-months pace was the right calibration for the role I was in. It wouldn't be the right calibration for the role I'm in now.

— end of essay · published june 10, 2026 · 1,168 words · 6 min
[ if this moved you ]

keep reading.

three essays in the same key · pick one