Coding in public: with filament and the tall stack If you're interested to take part in open source,  coding in public is naturally something we do. Here is an opportunity to come along with me on my own path to do the same.I've been looking for a way to share what I've learnt in my time and for that to be useful, not just for you the reader, but also for me. At the beginning of 2026 I started work on a new repository share-lt. It is not the first open source I published but I hope it not to be the last either. share-lt The name is short for 'share light' and is a minimal viable content management system. It is based on previously privately hosted works I currently run for clients and our own business. share-lt is what this article been written with. The project is in alpha and has no version tag yet but as of its changelog for 6th January 2026 it has sufficient to write articles. I will add more as time goes on. Next will be an API that static website builders can use to publish   share-lt content. This I hope to be in similar fashion to other, much bigger apps and services in the 'headless CMS' space but with a fraction of the complexity and cost. changelog Self hosting is of course possible due to shar-lt's GNU AFFERO  LICENSE but this could also be a web service that I can host for others that prefer not to do so themselves. GNU AFFERO  LICENSE I have been able to create this application and others like it at record speed mostly thanks to the PHP Laravel framework. It has been by far the most cost effective and personally rewarding technical decisions I have made over years of building systems. So Why Laravel ? In short, in my current view, Laravel is at the forefront of batteries included full stack frameworks today. It is opinionated but I'm OK with the patterns it follows, Model View Control being at the core. There are many more patterns you will come across the more you dig into it. But I've so far found I can get projects up and running in a fraction of the time it took in the NodeJS world. Since around the mid 2010s I had an interest in front end applications targeted at the browser. My day job was a systems engineer and would be DevOps person. But I realised the need for more than command line interfaces being the only way I could ship application. Managers wanted solutions to be 'push button'. What is better than a fancy GUI if you are to wow your users?  A CLI did not always cut it. It was predictable then for me to move into the JavaScript front-end world and I tried to embrace JavaScript on both the back-and front as the opinion of the day was that context switching between the two hampered productivity. However, over time I found that the back-end in particular suffered constant churn with new versions and frameworks. Each time an upgrade could bring  breaking changes. There was just too much to deal with and it would have resulted in burnout for sure. PHP has been around for donkeys years and since Perl was my first language for the web, I was happy enough with PHP lingo. Laravel was not on my radar until I got so exasperated by NodeJS libraries and frameworks such as AngularJS and React. In COVID, 2020. I remember in particular, the react router project changed so radically as to feel like it just broke everything. YouTube brought up in my stream those talking about Laravel (then version 10). I took a look and got hooked. Having 2 or more different languages in a project is not a big deal when you work in DevOps as this is the way of things anyway so why baulk at a PHP back end and JavaScript front end ? I realised pretty quickly that Livewire and Filament almost removed the immediate need to code JavaScript. This convinced me to make the switch to Laravel for my own web services that needed a solid back end as well as fully public internet facing interfaces. I reasoned that Laravel could become for me an application gateway so to speak. I could still have Go, Python, Clojure, NodeJS, Bun, Deno or whatever services behind Laravel but Laravel, Sanctum, Passport even, affront of these services. behind Laravel affront of If all else failed, I could just keep it simple, and do everything in Laravel. With the later versions of Livewire you could even have Single Page Application (SPA) like functionality with little or no need to get your hands dirty with JavaScript or TypeScript. Fast forwarding to today and Laravel 12 is reaching its end as its annual release cycle dictates but I've been happy this year with its stability through numerous interim releases. Capping it all off and into the new world of AI driven development, Laravel keeps pace with its Boost plugin that adds AI MCP integration into copilot and other IDE plugins. I used to feel reluctant to go back to how I remembered PHP at the turn of 2000 ,but the language is not at all as primitive now. Laravel embraces modern PHP and this changes all that for me. The test driven approach of Laravel and its pragmatic 'just ship' mentality enabled me to re-evaluate and abandon a previous learnt distrust of the language. In technology, boring is good. You need predictability and reliability. Learning is good, productivity is better. Filament Tall Stack Filament is build on the 'tall stack' of Tailwind, Laravel, Livewire and Alpine I chose to use Filament in share-lt out of expediency and frustration with other frameworks that lacked this level of maturity. Filament is, I think, reason in itself to use Laravel if you need admin consoles without needing to develop another app atop of your own app to give operational control over the app. Filament give us a way to create apps that have all the features of an advanced app with management capabilities without needing to write all of that yourself. Filament give us a way to create apps that have all the features of an advanced app with management capabilities without needing to write all of that yourself. Filament give us a way to create apps that have all the features of an advanced app with management capabilities without needing to write all of that yourself. Admin interfaces are complex and hard to get right. There are so many things to do developing even the simplest applications. We don't have the time to re-write or re-invent what is already achieved by filament . After all, filament gives us what is likely better than we could create ourselves. Filament provides many features, for the the foremost being: easy and direct integration with existing or new data models and tables
automated creation of boilerplate for forms, form entry, view, delete and update
out of the box UI components that just work such as search, sort, bulk actions
is extendable using actions that for example, insert modals into edit workflows
it standardises on a good administration interface that just works for mobile and desktop easy and direct integration with existing or new data models and tables automated creation of boilerplate for forms, form entry, view, delete and update out of the box UI components that just work such as search, sort, bulk actions just work is extendable using actions that for example, insert modals into edit workflows it standardises on a good administration interface that just works for mobile and desktop I am still learning how to use Filament but without needing to spend six weeks in tutorial hell, I think you will find that in a few days you can get up and running with something useful and highly presentable to users. The only down side I needed to get my head round was how to tweak table and form entries to get the best results. For example, you can create post actions to update the next or other field in a form to 'slugify' a title. Laravel has string library functions and helpers for this and Filament can add these into form entries. If you've installed Laravel with Boost, AI does a pretty good job of writing these as you go along and prompt it. It is surprising how productive you can become now with MCP enabled agents. Its Always about Testing Perl, and the CPAN of old had a strong association with code quality and achieved this in part by testing. Without strong support for testing, any language or framework will fail in my view. There is good support for unit and feature testing in PHP and Laravel. For full web applications that include both back end and front end testing becomes more of a challenge. Pest4 was launched in 2025 and I believe will take on all aspects of testing and tooling from unit testing to headless browser based end to end testing. Mean time I am happy to use Dusk, Laravel's current and highly competent tooling for end-to-end testing applications that use JavaScript front ends. I remember using Selenium back in the day despite it being difficult (for me at the time) to learn and use. I needed something that could reliably test complex UIs and server side code. Selenium delivered but at cost. Dusk makes the learning and the delivery easier. It feels like a bit of extra PHP in your test folder. and server side Lessons Learnt Testing In the past I now realise, I introduced what could become brittle tests by writing test setup for re-use. I am not a tester by trade and thought this was expedient. I think this is a pattern that some follow but as a generalist, DevOps and hybrid person I can and do make mistakes. I suppose we all do. My mistake was to not fully embrace test isolation. Each test therefor needs to be set up from scratch so to speak. Setup, such as user creation, permissions, fixtures and so on need to be included for each test. This can feel like duplication. I then have each subsequent test re-setting up say, a user, a database table, whatever is required but each time from a blank slate. Tests are ordered in a way that builds on the previous ones, each increasing in dependency. When a test fails, it should then be obvious what has been broken without having to traverse through a bunch of setup and dependencies to find I broke a setup step, not a test. Let us hope so anyway. That is the approach I am going with with Dusk for now. Lets see how I get on and if I get the setup code as non repeated by abstraction as I can. I think testing and particularly automated testing is essential for any kind of success in software. Whats Next ? I came across another term aside of coding in public, that of 'dogfooding' which is used to describe the way you need to treat software if you want your users to like it. If you don't use the software you write, how can you expect your users to want to try it, let alone pay for its support ? coding in public dogfooding I thought I could combine the two ideas of 'coding in public' and 'dogfooding'. I plan to develop share-lt with these principles in mind. As eluded to earlier, this article is written using the current code from share-lt to do so. I have found so far it works and is even pleasant to use. It is better than my previous attempts at writing a CMS, thanks to Filament and the tall stack. So if you're thinking of dong the same, this could be a way to share what you know and share what you use in a way this mutually beneficial for the writer and the consumer. Why not take a look at share-lt, fork it, run it yourself or write your own passion project in Filament. Why not take a look at share-lt Give Laravel a go if you have not already. You wont regret it Let me know what your building, I’d love to know your thoughts and findings! Let me know what your building

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

YouTube

Why I Started Building My Own Containers (and What I Wish Tutorials Told Me)

Coding in Public With Filament: Building a Minimal CMS on the TALL Stack

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Minimal Viable Kubernetes: Finally, a Self-Hosted Cluster You Can Actually Run

2,100 Unique Visitors in 3 Days: Creating Valuable Content like this Free Building in Public Guide

5 Marketing Tips for Launching Your DeFi or Crypto Project

Choosing a SaaS Building Path: Build in Public or Private?

From Idea to App Store: How I Built an App Using 100% No-Code Tools

Full-Time Indie Hacker Vs. Side Hustle: The Different Ways of Chasing the Cheddar

Minimal Viable Kubernetes: Finally, a Self-Hosted Cluster You Can Actually Run

2,100 Unique Visitors in 3 Days: Creating Valuable Content like this Free Building in Public Guide

5 Marketing Tips for Launching Your DeFi or Crypto Project

Choosing a SaaS Building Path: Build in Public or Private?

From Idea to App Store: How I Built an App Using 100% No-Code Tools

Full-Time Indie Hacker Vs. Side Hustle: The Different Ways of Chasing the Cheddar

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps