What I've Learned Shipping FilaForms (90 Days In) | 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 InsightsWhat I've Learned Shipping FilaForms (90 Days In) ================================================= filaforms.app/blog [ Back to blog ](https://filaforms.app/blog) [ Insights ](https://filaforms.app/blog/category/insights) What I've Learned Shipping FilaForms (90 Days In) ================================================= Manuk Minasyan · June 5, 2026 · 6 min read Ninety days ago I pushed the launch post and went to bed convinced I had forgotten something. I had. A handful of things, in fact. None of them killed it, but I want to write them down before the memory rounds off into a neat story. This is not a victory lap. The numbers are small and I know it. It is also not a postmortem — FilaForms is alive, customers are using it, and the roadmap looks better than it did on day one. What this post is: a status check at the ninety-day mark, written for the version of me who was on day zero, hovering over the Publish button, trying to decide whether to ship. If you are a solo dev about to launch a Laravel-ecosystem product, I think a few of these will land. I have left in the parts I would have wanted someone else to say out loud. The number ---------- FilaForms has 150 paying customers. Monthly revenue is hovering around $2,400. Free signups and waitlist conversions sit north of 5,000. That is the headline, and the headline is smaller than I want it to be. It is also bigger than the inner critic who lived in my head on day fifteen told me it would be. Both things are true. The trajectory matters more than the absolute number at this stage. Week one was a spike. Week two and three were a cliff. Week four onward has been a slow, uneven climb — most weeks up, a couple flat, none down. The shape is the shape of a product that has a real audience, not a viral moment. I will take that shape. A viral moment would have lied to me about what was working. What worked ----------- Three things did real work in the first ninety days, and I want to be specific about why. The launch post on r/laravel got the first wave of signups. Not because the post was clever — it was a plain "I built this, here is what it does, here is who it is for." It worked because r/laravel rewards specificity and punishes pitch language. I wrote it like a developer telling another developer about a tool, and the comments did more for trust than any marketing page I have written. One-time pricing made the buying decision instant. I had been talked into a subscription plan in the early drafts, and changing back to a one-time license a week before launch is the best product decision I made all quarter. Developers buying a tool for their own toolkit do not want a recurring charge. The friction drop was visible in conversion the first day. The architecture post outperformed every other piece of content I shipped. Writing about how the plugin is built — the events, the resource layout, the storage decisions — pulled in readers who became buyers a week later. Build-in-public works, but the specific lever was technical depth, not the founder-journey style. Show the work. The work is what other developers want to read. What didn't work ---------------- There was a tactic in the first thirty days that I was confident would move the needle. It did not. Worse, it cost me a week of attention I could have spent on the things that did. The frustrating part is that I could see in the analytics by day four that it was not working, and I kept going for another six days because I had told people I was doing it and pulling back felt like admitting I was wrong. The lesson under the lesson: I had no kill criteria in place before I ran it. I had a hypothesis and a hope, and when the hope did not match the data, I had no pre-agreed line that told me to stop. Next time I ship a tactic I will write the kill criteria first, on the same page as the plan, where I cannot pretend I did not see it. If you are about to launch, write the kill criteria for your launch tactics before you run them. Then look at them on day four. What I underestimated --------------------- The most common pre-purchase objection turned out to be whether the plugin would behave cleanly inside an existing codebase — not pricing. I was braced for pricing pushback. I had three different responses queued up for "is this worth it" conversations. I used none of them. The actual questions that came in were operational — whether the plugin would behave inside an existing codebase, whether the data stayed where the customer expected it to stay, whether the install would touch things it should not touch. The kind of questions you ask when you trust the product to do its job but do not trust it to do that job inside your specific setup. I had not written the documentation that answered those questions. I had written the documentation that answered "what is FilaForms," which is the question nobody who was about to buy was asking. The buying question was "will this slot in cleanly," and the docs were not aimed there. Fixing that mid-quarter unlocked conversations that had been stuck for weeks. If you are launching a developer tool, do not write the marketing-page version of the docs. Write the "I am about to install this in my real app" version. That is the page that sells. What I'd do differently ----------------------- Compress the gap between shipping and listening. The honest version of that is — I shipped fast and then went into a defensive crouch for two weeks, treating every piece of inbound as either a fire to fight or a feature to spec. The conversations I had a month later, when I had calmed down enough to ask follow-up questions, taught me more about the product than the launch week did. If you are about to ship, schedule the customer conversations into your week before they have anywhere to go. Put thirty minutes on the calendar three times a week and reach out to the people who bought, the people who signed up and did not buy, and the people who looked and bounced. The signal is in those conversations, not in the dashboard. The dashboard tells you what happened. The conversations tell you why. What's next ----------- Q4 is about turning the plugin into a platform — the cloud option, deeper integrations, and the parts of the roadmap I have been quiet about while I learned what the first customers needed. I will write a full roadmap post when the work is far enough along to commit to dates, not just intentions. Thank you --------- To the people who bought FilaForms in the first ninety days — thank you. You picked up a product before it had a hundred customers and you sent feedback that shaped the next version. That kind of early trust does not show up in any metric, and it is the reason there is a Q4 plan at all. If you have been on the fence, the [pricing page](https://filaforms.app/pricing) is here. If you are building something of your own and any of this was useful, that is a better outcome than a sale. Ship the thing. Then write down what happened. Related posts ------------- [ 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) [ 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)