The Quiet Cost of Rebuilding Forms on Every Project | FilaForms [ ![Filaforms Logo](https://filaforms.app/logo.svg)FilaForms ](https://filaforms.app) [ Features ](https://filaforms.app#features) [ Pricing ](https://filaforms.app#pricing) [ Blog ](https://filaforms.app/blog) [ Documentation ](https://docs.filaforms.app) [ Try Demo ](https://filaforms.app/login) [ Get Started ](https://filaforms.app#pricing) [ Features ](https://filaforms.app#features) [ Pricing ](https://filaforms.app#pricing) [ Blog ](https://filaforms.app/blog) [ Documentation ](https://docs.filaforms.app) [ Try Demo ](https://filaforms.app/login) [ Get Started ](https://filaforms.app#pricing) ![FilaForms](https://filaforms.app/logo.svg) FilaForms InsightsThe Quiet Cost of Rebuilding Forms on Every Project =================================================== filaforms.app/blog [ Back to blog ](https://filaforms.app/blog) [ Insights ](https://filaforms.app/blog/category/insights) The Quiet Cost of Rebuilding Forms on Every Project =================================================== Manuk Minasyan · July 21, 2026 · 6 min read A new client signs. Kickoff is on Tuesday. By Wednesday afternoon someone says it: "We'll need a contact form. And a referral form. And probably an internal request form for the ops team." Everyone nods. Nobody flinches. The form work goes into the estimate as a single bullet, maybe a day, maybe a day and a half. It is treated as warm-up. Setup. The thing you do before the real work. And then, like every project before this one, your team quietly rebuilds the same thing they built last quarter. A migration for the submissions table. A Filament resource to view them. A notification mailable for the client. A CSV export. Maybe a chart on the dashboard. Maybe a Slack webhook if the client is fancy. The field names are different. The styling is different. The underlying shape is identical to what you wrote six months ago, for a different client, on a different codebase you no longer have access to. I did this for about five years before I sat down and added up the hours. The number was embarrassing. Not catastrophic, not "we should shut down the agency" — just a steady, invisible leak in every quote we wrote. The four-times pattern ---------------------- If you run a small Laravel shop, you have built this stack at least four times: A model for the submission. A migration with a JSON payload column or twenty individual columns, depending on which junior was in a hurry. A Filament resource so the client can read responses. A notification — usually a mailable that says "you have a new submission" with a few highlights. A CSV export, because someone in finance always asks. Maybe a basic dashboard widget showing submissions per day. Maybe a webhook posting to Slack so the client doesn't have to log in. That is the whole pattern. It is the same on every project. It is also, on every project, written fresh. The field names change. The validation rules change. The brand colors change. The shape of the code underneath does not change. It is the same shape it was on the last project, and the one before that. The math, honestly ------------------ Six hours is what it takes a competent mid-level developer to build a basic form module from scratch. Model, migration, resource, mailable, CSV export. Six hours assumes nothing goes wrong. Eight is more realistic. Ten if there is conditional logic or a multi-step flow. Call it six hours so the math is conservative. Six hours per form module. A typical client project has one or two of these. Across a year, a small agency ships maybe five client projects with form work. That is somewhere between thirty and sixty hours of rebuilding the same shape. At a $150 an hour blended rate — and I am being kind, most agencies bill $175 to $250 — that is $4,500 to $9,000 of dev time per year, spent rewriting code you have already written, on a stack you already know, for a problem you already solved. Across five projects, you are looking at $22,500 of billable time spent on a thing that should be a dependency. It does not feel like that in the moment. In the moment it feels like an hour here, an afternoon there. Just the form stuff. Just setup. Why we keep doing it -------------------- This is the part that took me longest to be honest about. The first reason is the comfortable one: "this client is different." Their form has a signature field. Their form has a custom approval flow. Their submissions need to land in HubSpot, not Mailchimp. So a fresh build feels justified. It almost never is. The differences are at the edges. The core is the same. The second reason is harder. Estimating new code is psychologically easier than estimating integration of an existing solution. When you write something fresh, you control every line, and your estimate feels safe. When you integrate a package — even your own internal one — you have to remember how it worked, fight whatever you got wrong the first time, and explain to the team why the abstraction is the way it is. New code feels cheap. Integration feels expensive. The numbers say the opposite. The third reason is plain old NIH. Your last project's solution was "a bit different." So you reach for a blank file instead of the package. I have done this. I am not above it. Nobody is. The shift that helps -------------------- The shift is not "build a better internal package." Most agencies have an internal package. Most internal packages are abandoned by the second engineer who joins after the founder. The shift is treating form infrastructure the way you treat your database driver, your auth layer, or your queue. Nobody at your agency reinvents authentication on every project. Nobody writes a new queue driver because the client's job queue is "a bit different." You pick a thing, you learn it deeply, you trust it across projects. When the client need is at the edge, you extend, you don't rewrite. Forms deserve the same treatment, because they show up on every project. Contact forms. Lead capture. Internal requests. Job applications. Event signups. Surveys. The pattern is so consistent that treating it as a fresh feature each time is not pragmatism. It is a habit dressed up as pragmatism. This is part of why FilaForms exists, and I will keep that pitch short: pick something — your own package, an open-source one, a SaaS, doesn't matter — and commit. The win is in the commitment, not the tool. Three questions I would ask any agency owner -------------------------------------------- If you run a Laravel shop and the math above made you wince, sit with these for a minute. How many times has your team built the same submissions admin table? Count the projects honestly. Not the ones where the form was wildly custom. The boring ones. The contact forms. Can you list the slight differences that justified rebuilding each time? Write them down. Look at the list. Were they real architectural differences, or were they styling and field names? If the answer was "the client wanted custom branding" or "they had a different validation rule" — is that a reason, or a habit? Would you accept that justification for rewriting your auth layer? Forms are infrastructure ------------------------ Most teams treat forms as features, because forms get rebuilt per project the way features do. But the pattern underneath every form module is infrastructure, and the cost of pretending otherwise shows up as a slow leak across every quote your team writes. You do not have to use [FilaForms](https://filaforms.app). You do have to pick something. The cost of not picking is not visible in any single project. It shows up in the features you did not ship, the weeks you did not have, the margins that quietly went somewhere else. Related posts ------------- [ Insights Jun 5, 2026 What I've Learned Shipping FilaForms (90 Days In) --------------------------------------------------- Ninety days ago I shipped FilaForms. Here's what's worked, what hasn't, the number I underestimated, and the launch tactic I'd skip if I did it again. ](https://filaforms.app/blog/what-ive-learned-shipping-filaforms-90-days-in) [ Insights Apr 6, 2025 How I built FilaForms: architecture decisions behind a Filament plugin ------------------------------------------------------------------------ The technical and product decisions behind FilaForms — why JSON storage, why SHA-256 analytics, why Custom Fields as a foundation. ](https://filaforms.app/blog/how-i-built-filaforms-architecture-decisions-behind-a-filament-plugin) [ Insights Mar 11, 2025 Why every Laravel app needs a form builder (not just code) ------------------------------------------------------------ You can code forms in Laravel. The question is whether you should keep doing it manually on every project when a form builder handles the plumbing. ](https://filaforms.app/blog/why-every-laravel-app-needs-a-form-builder-not-just-code) ![FilaForms Logo](/logo.svg) FilaForms Laravel form infrastructure for Filament. Stop rebuilding forms on every project. ### Product [ Features ](https://filaforms.app#features) [ Documentation ](https://docs.filaforms.app) [ Blog ](https://filaforms.app/blog) [ Pricing ](https://filaforms.app#pricing) [ About ](https://filaforms.app/about) [ Contact ](mailto:hello@filaforms.app) ### Legal [ Terms of Service ](https://filaforms.app/terms-of-service) [ Privacy Policy ](https://filaforms.app/privacy-policy) © 2025-2026 FilaForms. All rights reserved. [ ](mailto:hello@filaforms.app) [ ](https://x.com/MinasyanManuk)