At the beginning of 2026, we said we wanted to go deeper and wider. Deeper into the ecosystems we already work with. Wider in how we use open source, AI, automation, and internal tooling to solve real problems. Six months later, that direction feels much clearer.

The first half of the year was not shaped by one big launch or a perfectly followed roadmap. It was shaped by questions that kept appearing during everyday work.

How can someone get started with Frappe without spending hours on setup? How can developers discover useful apps and understand compatibility? Can Frappe run inside a browser? Can ideas from WordPress improve Laravel and Filament workflows? Can AI make long-postponed migrations more practical?

Most of what we built began with questions like these. Some became products. Some became open-source projects. Some are still experiments. Together, they show where Lubus is heading.

Going Deeper Into Frappe

At the end of 2025, we shared that Frappe would become a bigger part of our work.

We were already using it for internal operations and client solutions. What we did not fully anticipate was how quickly that would lead us from implementing Frappe to building tools around its ecosystem.

The first problem was local setup. Frappe is powerful, but getting started can still involve dependencies, containers, version management, site creation, and troubleshooting before someone can properly explore the framework.

That led to Frappe Local, a desktop application for creating and managing local Frappe environments through a simpler interface. We did not build it to replace Bench. We built it for people who want an easier entry point, whether they are learning Frappe, evaluating apps, managing sites, or working on customizations.

It began as an internal tool and became an open-source public beta by June. While building it, another problem appeared: app discovery. Finding the right app, checking compatibility, and understanding its metadata is often harder than installing it. A small metadata script gradually became Frappe Brewery, an open app registry with listings, categories, compatibility information, repository metadata, and JSON APIs. Its first major integration is with Frappe Local, allowing users to discover apps directly inside the desktop application.

Then came our most experimental project: Frappe Playground. The question was simple: if WordPress can run inside a browser, could Frappe do something similar? The result was a working proof of concept built with WebAssembly, Pyodide, and SQLite. It runs Frappe inside a browser tab without a traditional server. It is still early, but the possibilities are interesting: learning, demos, documentation, reproducible examples, and quick exploration without installation.

Frappe Local, Brewery, and Playground were not planned as a suite. One problem exposed another, and each experiment opened the door to the next. That is often how our most meaningful open-source work begins.

Building Better WordPress Workflows

While Frappe became a larger part of our experiments, WordPress remained central to our client work and open-source efforts.

Our focus stayed the same: build close to Core, reduce unnecessary layers, and improve everyday publishing workflows. One of the useful releases was Query Loop support for BlaBlaBlocks Slider Block. Rather than creating another custom query system, we integrated Slider Block with the Core Query Loop block. WordPress decides which content appears. Slider Block decides how it is presented.

We also continued improving BlaBlaBlocks Formats with Typography Format and Clear Formatting, both created to solve recurring editor problems around inline styling and pasted content.

The same thinking shaped Color Palette Block v2, rebuilt for brand pages, style guides, documentation, and case studies with multiple swatches, layouts, theme colours, and copyable colour formats.

We also started sharing BlaBlaBlocks Popup, a block-based popup tool designed to feel native to WordPress rather than like a separate builder.

Tabs and Slider Block crossed 600+ active installations after being featured on WordPress.org too. Six hundred is not a huge internet number. For a small independently maintained plugin, however, it means hundreds of people trusted something we built enough to use it. That matters to us.

Ideas Travelling Across Ecosystems

Working across WordPress, Laravel, Filament, and Frappe often creates useful overlaps.

Our experience with the WordPress Block Editor influenced Filament Builder, an experiment for visually composing FilamentPHP schemas. Filament is already an excellent code-first framework. The challenge appears when forms, tables, layouts, actions, and nested components become difficult to plan.

Filament Builder explores a visual layer with a component palette, configurable properties, structural previews, and exportable schemas. It is not intended to replace code. It is meant to make the thinking before the code easier.

This is one of the things we enjoy most about working across ecosystems. A pattern learned in WordPress can improve a Laravel workflow. A local development experience can inspire a Frappe tool.

Ideas become more useful when they are allowed to travel.

Finding Practical Leverage With AI

At the beginning of the year, we wanted to move beyond casual AI experimentation and find practical ways to use it.

One result was Frappe Skills, a reusable knowledge layer that gives AI development tools better context about Frappe patterns, APIs, testing, conventions, and project structure. It began as internal context for our own work and was later released publicly.

We also tested AI-assisted migration using Xenio, one of our older fintech products built with Microsoft ASP.NET. Modernizing it had been on our list for years, but the starting cost always felt too high. AI changed that enough for us to revisit it. After a focused experiment, we reached a functional first-level migration to Laravel and Filament.

It was not automatic or production-ready. Experienced developers still had to review architecture, correct mistakes, and make important decisions. The value was not that AI replaced engineering. It made a difficult starting point more approachable.

Across the team, AI is also becoming part of prototyping, documentation, testing, and development. We are still learning where it creates real leverage and where traditional approaches remain better.

Our goal is not to add AI to everything. It is to use it where it genuinely helps.

Moving Gymie Forward

Gymie also continued moving through its next chapter.

We began the year by building a more intentional mobile design system and shared React Native components that could evolve with the product. As Gymie v3 moved into close beta, conversations with gym owners and staff brought the focus back to clarity.

They did not ask for endless features. They wanted everyday information to be easier to find. That led us to improve the dashboard around memberships, renewals, check-ins, and the overall health of the gym.

We also began expanding language support, with English, French, and Arabic among the first options. By May, we had launched a refreshed Gymie website and opened the early-access waitlist.

The next phase is less about building in isolation and more about learning from real users.

Client Work Still Grounds Everything

Open-source projects are often the most visible part of what we share, but client work remains the foundation that keeps our ideas practical.

Many of the tools we build publicly begin with recurring needs from client projects. Typography Format came from content-editing problems. Color Palette Block grew from brand and documentation work. Slider Block’s Query Loop integration came from dynamic publishing requirements. Our Filament experiments came from solving similar problems across applications.

The line between client work, internal tools, products, and open source is rarely clean at Lubus. That is intentional. Client work shows us real constraints. Internal usage tests our assumptions. Products make us think long term. Open source invites others into the process.

Each part makes the others stronger.

What the First Half Taught Us

At the start of the year, our plans were broad: more FOSS, deeper WordPress work, stronger Frappe solutions, more Laravel and Filament tools, practical AI adoption, and continued progress on Gymie.

We have made progress across all of them. What is more interesting is how they have started connecting.

Frappe Local led to Brewery. Local and Playground now explore two different ways of making Frappe easier to access. Gutenberg influenced Filament Builder. Client work continued feeding BlaBlaBlocks. AI helped us document how we build and revisit a migration we had postponed for years.

The pattern remains simple. Use the tools deeply. Notice the friction. Build what is missing. Use it ourselves. Share it when it becomes useful. Not every experiment will become a mature product. Some may remain proofs of concept. Others will change direction.

That uncertainty is part of building.

The Second Half of 2026

The next six months will be about turning experiments into more dependable tools.

For Frappe Local, that means improving stability, expanding platform support, and refining Brewery integration. For Frappe Playground, it means finding where a browser-based environment provides real value beyond the technical experiment.

We will continue improving BlaBlaBlocks, with Popup becoming a major focus alongside Slider, Tabs, Formats, and our other WordPress tools.

Gymie will move further into early access. Filament Builder and our Laravel experiments will continue evolving through internal and client usage.

AI will remain part of the work, but not the headline of every project. We are more interested in the leverage it creates than the label attached to it. Most importantly, we want to keep sharing what we learn openly.

The first half of 2026 reminded us that useful work does not always begin with a grand plan. Sometimes it starts with a difficult setup process, a repeated client request, a missing piece of metadata, or a late-night question about whether an entire framework can run inside a browser.

You follow the question. You build a small version. You use it. Other people become interested. Slowly, it becomes something larger. That has been our year so far.

Tools we need. Tools we build. More brewing ahead.