DEV Community: Joni Ilman Pahmi

I Turned My WordPress Store Into an MCP Server. Now an AI Agent Runs My Business — With My Permission.

Joni Ilman Pahmi — Fri, 09 Oct 2026 00:25:37 +0000

Or: how a WordPress plugin, an embedded OAuth 2.1 authorization server, and a blue slime named Blub are teaching AI agents to ask before they act.

The story that started it all

One evening, an AI agent created a product in my WooCommerce store.

Not through a hack. Not through a leaked admin password. And not because I gave an AI unrestricted access to my WordPress dashboard.

It proposed the action, I reviewed the details, and I approved it through an admin dashboard.

The product was "Cilok Goang Pedas Mantap" — a spicy Indonesian street-food product — with its price, sale price, stock, SKU, categories, tags, and SEO metadata configured through an AI-assisted workflow.

The agent was Meta's Muse Spark, accessed through Muse Code.

The bridge that made this possible is called MuseSpark MCP Bridge.

It's a WordPress plugin that turns a WordPress + WooCommerce installation into an MCP server, allowing AI agents to interact with business data through structured tools rather than relying entirely on browser automation.

And the part I care about most isn't that an AI can create a product.

It's that I can decide what it is allowed to do.

What is MuseSpark MCP Bridge?

MuseSpark MCP Bridge exposes selected WordPress business capabilities through the Model Context Protocol (MCP).

Instead of building a separate integration for every AI agent, the plugin provides a standardized interface for operations such as reading posts, managing product inventory, creating content, updating SEO metadata, and generating daily business summaries.

Here's the current toolset:

Tool	Access	Purpose
`wp_list_posts`	Read	Retrieve WordPress posts
`wp_create_post`	Write	Create content or drafts
`seo_set_post_meta`	Write	Update Yoast SEO metadata
`wc_list_products`	Read	Retrieve WooCommerce products
`wc_create_product`	Write	Create WooCommerce products
`wc_update_stock`	Write	Update inventory
`newsletter_add_subscriber`	Write	Add a newsletter subscriber
`report_daily_summary`	Read	Generate a daily business summary

The server implements the MCP 2025-06-18 specification over Streamable HTTP, including the relevant initialization, ping, tools, resources, and prompts protocol methods.

It has been verified end-to-end with the official MCP Inspector, including the OAuth authorization flow over HTTPS.

The project has also been tested in live Muse Code sessions using Muse Spark, where the agent created real products and content drafts through the approval workflow.

This is still an evolving prototype, but the basic integration is already doing useful work.

Why MCP instead of another custom API?

WordPress already has a REST API. WooCommerce has its own API. So why introduce MCP?

Because exposing an API and giving an AI agent a usable interface to business operations are two different problems.

A conventional API gives applications endpoints and data structures. MCP provides a standardized way for compatible AI clients to discover and invoke tools.

For example, instead of asking an agent to figure out how to construct a series of HTTP requests to create a product, I can expose a tool called wc_create_product with a defined input schema.

The agent can reason about the available tool, prepare its arguments, and request the operation through the MCP server.

The plugin then handles the WordPress-side integration and applies its authorization and autonomy policies.

This doesn't make every AI agent automatically compatible, nor does it eliminate the need for proper validation. It simply gives compatible clients a more consistent interface to work with.

The architecture looks like this:

AI agent → MCP client → MuseSpark MCP Bridge → WordPress / WooCommerce

The AI handles reasoning and tool selection. WordPress remains the source of truth for business data.

And the bridge determines how those tool requests are handled.

The part I'm proudest of: the AI asks for permission

Giving an AI agent access to a business system is easy to demonstrate.

Building a sensible boundary between what the agent can propose and what it can actually execute is the more interesting engineering problem.

MuseSpark MCP Bridge includes an autonomy policy engine with three modes.

1. `read_only`

The agent can inspect permitted business data, but write operations are not allowed.

This is the mode I'd start with when connecting an unfamiliar agent to a real store.

2. `draft_only`

The agent can prepare drafts rather than directly publishing content.

This is useful for workflows where AI can do the repetitive preparation while a human retains editorial control.

3. `require_confirmation`

This is the default mode.

When a write action requires confirmation, the plugin routes the request to an approval queue rather than immediately executing the requested operation.

I can review the proposed payload in the admin UI, approve it, or reject it. The action runs only after approval.

The distinction matters: an agent requesting an action is not the same as an action being authorized to execute.

The server also validates scopes at request time and records them with the task for auditing.

That creates a clearer record of what was requested and under which permissions it was processed.

Of course, an approval queue isn't a substitute for secure authorization, input validation, or proper capability checks. It's one layer in a broader security model.

But it's an important layer.

I don't want an agent to accidentally publish a product with the wrong price just because it misunderstood my instructions. And I certainly don't want a compromised integration to have unrestricted write access to my store.

OAuth 2.1, built into WordPress

One of the more substantial parts of this project is its embedded OAuth 2.1 authorization server.

Rather than relying exclusively on manually generated credentials, the plugin implements an authorization flow designed for compatible MCP clients.

The current implementation includes:

Protected resource metadata under RFC 9728.
Authorization server discovery under RFC 8414.
Dynamic client registration under RFC 7591.
Mandatory PKCE using S256.
A user consent screen.
Refresh-token rotation.
Token revocation.
A legacy scoped JWT bearer-token option for supported workflows.

Tokens and authorization codes are stored as hashes rather than plaintext credentials. The plugin also provides audit logging and an admin interface for managing tokens, approvals, logs, and settings.

For command-line workflows, a scoped JWT can be generated through WP-CLI:

wp musespark generate-token \
  --user_id=1 \
  --scopes='*' \
  --ttl=3600

That example deliberately requests all scopes, so it should be treated as a development example, not a recommended production configuration. In a real deployment, use the narrowest permissions the workflow needs and an appropriately privileged WordPress account.

OAuth implementation details are not a guarantee of security by themselves. The project still needs further hardening, and I don't consider the current prototype production-ready.

That distinction is important enough to say explicitly.

BYOK: Bring your own agent

My philosophy is simple: the plugin ships no AI model.

There is no bundled model, no AI inference proxy, and no per-token markup. MuseSpark MCP Bridge is an integration layer, not an AI platform.

The responsibilities are deliberately separated:

The agent reasons about the task and decides which tools to request.
The MCP server exposes structured business capabilities.
WordPress remains the source of truth.
The authorization and policy layers determine which operations are permitted and whether approval is required.
The human operator retains control over sensitive actions.

Muse Spark through Muse Code is the first agent workflow I've verified end-to-end with this project.

Because the server implements MCP rather than a proprietary Muse-specific tool protocol, other compatible MCP clients can potentially use the same endpoint too. Claude Desktop, Cursor, and custom agents are examples of clients worth exploring, but compatibility and authorization flows must be tested individually.

This is the architectural advantage I want to preserve.

If I change AI providers tomorrow, I shouldn't have to rebuild the entire WordPress integration just to expose the same business operations to another agent.

One backend. A standardized interface. Different potential agents.

That's a much more interesting proposition to me than tying a business workflow to a single AI vendor.

Meet Blub 💙

Every serious security project needs an unserious mascot.

Meet Blub, a chubby blue slime with an operator headset who lives in the admin dashboard.

Blub is there to greet the operator and keep the approval workflow a little less intimidating.

The mascot also has a small origin story: I briefly considered using a third-party mascot as a local easter egg, then decided that building an independent identity was the better choice.

So I created Blub instead.

His catchphrase is:

"Blub!"

Depending on the context, it roughly means, "The task is done."

The plan is to bring Blub into future chat-based workflows, including a Telegram control bot with inline approval and rejection actions.

That integration is on the roadmap, not a shipped feature yet.

Still, I like the idea of a friendly little slime reminding me that an AI agent has something waiting for my approval.

Security doesn't have to look intimidating to be taken seriously.

What works today, and what doesn't?

I'd rather be precise about the project's status than turn a working prototype into a production-readiness claim.

MuseSpark MCP Bridge is currently at v0.2.x.

What's been verified

MCP protocol interaction through the official MCP Inspector.
An end-to-end OAuth flow over HTTPS with MCP Inspector.
Live Muse Code sessions using Muse Spark.
Real WooCommerce product creation through the approval workflow.
Content-draft workflows through the same integration.
The WordPress admin interface for managing tokens, approvals, logs, and settings.

What's still missing

An automated PHPUnit and integration-test suite.
Rate limiting.
Further OAuth and security hardening.
The final WordPress.org submission package.
Planned chat gateways and more granular autonomy controls.

These aren't minor footnotes. They're part of the work required before I would recommend treating the project as a production-ready business integration.

The current implementation is functionally verified in specific workflows, but that is not the same as having comprehensive automated coverage or a completed security review.

I'd rather publish an honest roadmap than pretend those gaps don't exist.

What's next?

There are four areas where contributions could make a meaningful difference.

1. Automated testing

The biggest gap is a proper PHPUnit suite and an integration harness covering authorization, scopes, tool execution, approval decisions, and failure cases.

2. Chat-based control

A Telegram bot with inline approve/reject buttons is planned. WhatsApp Cloud API integration is another potential direction, particularly for customer-service workflows.

3. More granular autonomy policies

The current three policy modes provide a starting point. The roadmap includes per-domain autonomy levels, from tightly controlled operations to more autonomous workflows, with appropriate boundaries.

4. Documentation and deployment

Installation instructions, OAuth flow documentation, translations, and a cleaner distribution package all need continued work.

If you want to explore the code, report a bug, or contribute, start here:

Repository: https://github.com/joniilmanfahmi00-collab/musespark-mcp
Contributing guide: https://github.com/joniilmanfahmi00-collab/musespark-mcp/blob/main/CONTRIBUTING.md
Security policy: https://github.com/joniilmanfahmi00-collab/musespark-mcp/blob/main/SECURITY.md

The project is distributed under GPL-2.0-or-later.

MuseSpark MCP Bridge is an independent community integration. Muse, Muse Spark, and related marks belong to Meta Platforms, Inc.; the project is not affiliated with, endorsed by, or sponsored by Meta.

Your business, your rules

I started this project because I wanted to explore a practical question:

What happens when an AI agent can interact with a real business system, instead of merely explaining how a human could do it?

The answer isn't that the AI should automatically become the administrator of everything.

It's that we can give agents specific tools, define their permissions, record what they do, and require human approval where it matters.

A WordPress store doesn't need to surrender control to benefit from AI automation.

It needs a reliable interface, a clear authorization model, and sensible limits on what an agent can do.

That's what I'm trying to build with MuseSpark MCP Bridge.

If you'd like to explore the current prototype, check out the repository:

GitHub: MuseSpark MCP Bridge

For a local or development installation, a compatible MCP client can connect to the endpoint:

https://your-site.test/wp-json/musespark-mcp/v1/mcp

Replace the example hostname with your own WordPress site's HTTPS URL, and configure the client using the authentication method it supports.

This is a prototype, so review the setup and security requirements before connecting it to a live store.

The long-term goal is straightforward: let the agent do the repetitive work, let the system enforce the boundaries, and let the human remain in control.

And when there's a task waiting for approval?

Blub! 💙

Alisha Catat: a local Gemma order assistant for my friend small print shop in Ciamis, Indonesia

Joni Ilman Pahmi — Sun, 04 Oct 2026 23:56:47 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

Meet Alisha Cetak, a small print shop in Cisontrol, Rancah, Indonesia, owned by my friend A Asep, who agreed to be named in this article.

Like many small businesses, the shop handles practical, everyday work: banners, photo prints, ID cards, invitations, and other printing orders. Prices are maintained on a poster, while order details and transactions have traditionally been recorded by hand.

That workflow works, but recording orders, calculating prices, tracking down payments, and preparing sales summaries can become repetitive.

So I built Asep a small order assistant powered by a locally running Gemma model.

The idea is simple: let the owner describe an order naturally, then let the application turn it into structured, verifiable business data.

For example, Asep can type an order like this:

Pak Dedi pesan spanduk 3x1 dua lembar, DP 100rb

In English, that roughly means:

Mr. Dedi orders two 3 × 1 metre banners, with a 100,000 IDR down payment.

The application extracts the relevant information, matches the item against the shop's price list, calculates the price, and presents a confirmation screen before saving the order.

Once saved, the data can be used to produce receipts in PDF, Excel, or image format for sharing through WhatsApp. The application also provides daily, weekly, and monthly sales reports.

The goal isn't to replace the shop owner with an AI agent. It's to reduce repetitive administrative work while keeping the owner in control of every transaction.

Demo

Demo: CLICK ME!

Screenshots:

I'd also like to include a photo of Asep using the application at his counter, with his permission and with customer information hidden.

The application has been tried at the shop. This is an early, practical use case rather than a claim that the system has already been validated across hundreds of transactions.

Code

Repository: https://github.com/joniilmanfahmi00-collab/alisha-catat

The application is built with Solid-Vue JS, my own Vue + Vite framework with file-based API routes powered by h3.

The rest of the stack includes:

Ollama + Gemma 3 for local language-model inference.
SQLite + Drizzle ORM for local data storage.
Tailwind CSS for styling.
Tabler Icons for interface icons.
Chartist for sales charts.
pdf-lib for PDF receipts.
ExcelJS for Excel exports.
Decimal.js for monetary calculations.

How I Built It

1. A local model running on modest hardware

I used gemma3:4b through Ollama on my development machine:

AMD A8-9600 CPU
8 GB RAM
No dedicated GPU

This was an important constraint. I wanted to explore whether an open-weight model could be useful for an actual small-business workflow without requiring a GPU, a cloud inference service, or a subscription to a hosted language-model API.

The model runs locally on the machine. For typed orders, the core order-parsing workflow does not require an internet connection.

The performance is not instant, but the experiment showed that a small local model can still be useful when the task is narrowly defined.

2. Gemma extracts data; ordinary code handles the money

One of the most important design decisions was limiting what the model is allowed to do.

Gemma is responsible for extracting structured information from the customer's natural-language order, including:

Customer name
Product or service
Dimensions or size
Quantity
Unit

The model returns JSON constrained by a schema.

For example, an order mentioning two banners measuring 3 × 1 metres should be represented as structured fields rather than left as an unstructured sentence.

The application then takes over.

Gemma does not decide the price, calculate the total, or determine the amount of money received.

Those operations are handled by deterministic application code:

The extracted product is matched against the shop's price list.
The price is calculated according to the applicable pricing rule.
The down-payment amount is parsed separately.
Monetary calculations use Decimal.js.
The resulting order is shown in a confirmation card.
The user can correct the extracted information before saving it.

The price list supports different pricing methods, such as per-unit prices, per-square-metre prices, per-pack prices, and manually entered price ranges where necessary.

This separation matters because a language model can misinterpret an order. It should not be trusted to invent a price or perform financial calculations without deterministic checks.

The model helps interpret the customer's words; the application remains responsible for the transaction.

3. A confirmation step instead of blind automation

I deliberately included a confirmation card rather than saving every model response immediately.

An incorrectly interpreted dimension, quantity, or customer name can create problems at a real print shop. Even a small mistake can affect the price or the final product.

The confirmation step gives Asep a chance to review and correct the extracted information before the order is stored.

If the model is unavailable or too slow, the same interface can be used as a manual form.

This fallback is important: the business workflow should not become unusable simply because an AI component is unavailable.

AI is an assistant in this application, not a mandatory dependency for every action.

4. From an order to a useful business record

After confirmation, the application stores the order locally in SQLite.

That record can then be used to generate receipts and sales summaries. Instead of treating each transaction as an isolated piece of handwritten information, the application makes the data available for daily, weekly, and monthly reporting.

The workflow is therefore more than a text-to-JSON demonstration.

It connects language-model inference to a practical business process: order entry, validation, pricing, record keeping, receipt generation, and reporting.

What I Measured

I ran a small experiment on the CPU-only development machine using five invented sample orders. These were test inputs, not a representative dataset from the shop, so the results should be treated as an initial observation rather than a rigorous benchmark.

Configuration	Correct extractions	Approx. time per order
Gemma 3 4B, longer prompt	5/5	37 seconds
Gemma 3 4B, shorter prompt	5/5	23 seconds
Gemma 3 1B, shorter prompt	4/5	11 seconds

For the 1B model, the missed extraction was flagged by a warning in the application.

Two lessons stood out.

First, prompt length matters on limited hardware. In this small test, shortening the prompt reduced the time per order from around 37 seconds to around 23 seconds. That is approximately a 38% reduction.

The result suggests that keeping the task focused and avoiding unnecessary prompt instructions can make local inference more practical. It does not establish that prompt processing alone accounted for the entire difference; these timings include the model's overall response time.

Second, a smaller model can be useful when paired with appropriate application-level validation. The 1B model was faster but made one mistake in five samples. The warning helped surface that problem rather than silently treating every output as correct.

These results are not enough to conclude that the smaller model is generally better or that the larger model will always be accurate. They simply helped me understand the trade-offs on my available hardware.

For a real deployment, I would want a larger and more varied test set, repeated timing measurements, and evaluation against actual orders with permission from the shop owner.

Already Used in the Shop

Asep has been trying the application at his counter. He shared the following feedback over WhatsApp and gave me permission to quote it:

intinamah mantap, aplikasina ringan, mudah di akses bisa offline oge. jeng mempermudah rekap harian sampai bulanan toko saya

In English, the message means approximately:

Overall, it's great. The application is lightweight, easy to access, works offline too, and makes it easier to recap my shop's sales from daily to monthly.

For me, this feedback matters more than simply demonstrating that a model can generate valid JSON.

The application was built for a particular person with a particular workflow, and he has started using it to see whether it helps with his work.

There is an important qualification to the offline claim, though.

Asep's shop PC does not have a microphone, so voice input is not part of his current daily workflow. He has mainly been using the typed-order flow.

The application can still be useful without voice input: he can enter an order, review the extracted data, confirm the transaction, and use the resulting records for reporting.

The same application could potentially support other small shops by letting them configure their own price lists and product types, although each shop's workflow and pricing rules would need to be checked.

Why Open Innovation Matters

For this project, open-weight AI and local inference were not just technical preferences. They made the approach practical for the environment in which the application was built.

1. No per-request cloud inference fees

A small print shop may not have enough order volume to justify a recurring AI service subscription.

Running Gemma locally avoids per-request fees for the model inference itself. There are still costs associated with the computer, electricity, maintenance, and software development, but the shop does not need to pay a hosted-model provider for every order parsed.

That makes the operating cost easier to predict.

2. Order data can stay on the shop's computer

For typed orders, the text is sent to the locally running model rather than a remote LLM API.

This reduces the need to transmit customer names and order details to an external inference provider.

Local processing does not automatically guarantee complete privacy or security. The computer, application, database, backups, and any other connected services still need appropriate protection. But keeping inference local gives the business more control over where its data is processed.

3. It can run without a dedicated GPU

The experiment used an AMD A8-9600 CPU and 8 GB of RAM, without a dedicated GPU.

The response time is a clear limitation, but the setup demonstrates that a local model can be explored on modest hardware.

Not every small business needs a powerful AI workstation. Sometimes a practical, slower solution is more accessible than a faster solution that requires new hardware or recurring service fees.

4. I can change the model and its behaviour

Using an open-weight model with Ollama lets me experiment with different model sizes, prompts, and structured-output approaches.

That flexibility made it possible to compare Gemma 3 4B and 1B on the same small set of sample orders and to adjust the prompt without being tied to one hosted API.

A closed API could also provide structured extraction, and I am not claiming that local inference is always more accurate or faster. The advantage here is having more control over the model deployment and the ability to run the core parsing workflow locally.

For this particular use case, those trade-offs are worth exploring.

Honest Limitations

The application is an early project, and there are several limitations worth making explicit.

Local inference is relatively slow. On my development machine, the tested configurations took approximately 11–37 seconds per order. Actual performance will depend on the hardware, model, prompt, and input.
The benchmark is very small. Five invented orders cannot establish production-level accuracy or reliability.
Human confirmation remains necessary. The extracted order must be reviewed before saving, especially when dimensions, quantities, or customer details affect the transaction.
Voice input is not guaranteed to work offline. It uses the browser's speech-recognition capability, which may rely on a remote service depending on the browser and implementation. Gemma processes the resulting text locally, but that does not mean the audio itself is processed locally.
The shop PC has no microphone. Consequently, voice input has not been part of Asep's daily usage.
Microphone access has browser restrictions. Browsers generally require a secure context, such as HTTPS or localhost, for microphone access. A phone opening the application over a plain HTTP LAN address may not be able to use the microphone. Keyboard dictation is an alternative, depending on the device.
Local does not mean maintenance-free. The application still needs backups, sensible access controls, error handling, and a plan for updates and data recovery.

I would like to improve the voice workflow and test the application against more varied orders. I would also like to collect feedback over a longer period before making stronger claims about how much time it saves.

What I Learned

This project reinforced a principle I keep coming back to: AI is most useful when it is given a clear responsibility inside a well-defined workflow.

Gemma does not need to understand the entire business. It needs to extract a small set of fields from a customer's order.

The application does not need to trust the model with financial decisions. It can validate the extracted data, apply explicit pricing rules, and ask the owner to confirm the result.

And the shop does not need a complex cloud-based architecture just to organise its orders and produce sales reports.

The technical challenge was not simply getting a model to respond. It was integrating the model into a workflow that remains understandable, controllable, and useful when the model makes a mistake or is unavailable.

That is also why I enjoyed building this for Asep. It connects software development with a real business problem rather than adding AI to an application just because AI is fashionable.

Prize Categories

I am submitting this project for consideration in the Best Use of Gemma category because Gemma 3 is the core model used to interpret natural-language orders.

The model is not a decorative chatbot attached to an otherwise unrelated application. Its structured extraction is what connects free-form order descriptions to the application's validation and pricing workflow.

Final Thoughts

Alisha Cetak started with a straightforward problem: order details were written by hand, prices were kept separately, and preparing sales recaps required additional work.

The result is a small, local-first order assistant that connects natural-language input to structured records, deterministic pricing, receipts, and sales reports.

It is not a perfect system, and I am not presenting five test orders as proof of production reliability. The model is slow on low-end hardware, voice input has limitations, and the application still needs more real-world evaluation.

But it has reached the point where its intended user can try it in his own shop and tell me whether it helps.

For me, that is the value of building for a friend: starting with a problem that matters to someone, choosing technology that fits the constraints, and being honest about what works and what still needs improvement.

Open innovation made it possible to experiment with a locally running model, avoid per-request inference fees, and keep typed order parsing on the shop's own computer.

Sometimes a useful AI project does not need to be a large autonomous agent. It can be a small, carefully scoped component that makes an ordinary business task a little easier.

Thanks for reading! I'd love to hear how you'd approach reliable local order extraction or genuinely offline voice input for a small business.

Industry Notes for 2026: Why I’m Choosing to Build for SMEs Instead of Chasing a Corporate Engineering Career

Joni Ilman Pahmi — Sat, 03 Oct 2026 23:24:12 +0000

Inspired by Theo’s discussion on VoidFnC about the realities of being a software engineer in 2026.

The software industry is changing rapidly. AI tools are becoming more capable, code can be generated faster than ever, and building an application is increasingly accessible to people who previously had little or no programming experience.

At first glance, this sounds like progress. And in many ways, it is.

But there is another side to this transformation: the expectations placed on software engineers are changing, too.

Recently, I watched a video by Theo, a software engineer and creator behind the YouTube channel VoidFnC, who discusses his experience in the industry spanning more than eight years. His video, “I Hate Being a Programmer in 2026” or "gue benci jadi programmer (di tahun 2026)" in Indonesian Speech, raised several concerns about the direction of software engineering.

I found his observations worth thinking about, particularly when considering my own direction as a developer.

This article is not an attempt to present Theo’s opinions as universally proven facts. It is my interpretation of the issues he raised, combined with my own perspective on software development, independent work, and the small and medium-sized enterprises (SMEs) I want to support.

1. AI Is Changing More Than the Way We Write Code

One of Theo’s central arguments is that AI hype is no longer confined to developers discussing frameworks, programming languages, or development tools.

It has spread to product managers, designers, business owners, executives, and other people who influence software projects.

Previously, unrealistic expectations about a new framework or programming language might have remained mostly within engineering teams. Today, AI-generated demonstrations and claims about rapid application development can influence business decisions directly.

Someone sees an AI tool produce a working prototype in minutes and concludes that a production-ready application should take only a fraction of the time it used to.

The problem is that a prototype and a production application are not the same thing.

A prototype may demonstrate that an idea is possible. A production system must also deal with authentication, authorisation, data integrity, security, error handling, deployment, monitoring, maintenance, and unexpected user behaviour.

The code that appears in a demonstration is only one part of the complete system.

When decision-makers underestimate these differences, the resulting expectations can become unrealistic before the engineering team even begins working.

The issue is not that non-technical people should stay away from software. It is that decisions about engineering work should be informed by the actual complexity and risks involved.

AI can help us build faster. It does not automatically make every deadline reasonable.

2. More Code Does Not Automatically Mean More Productivity

Another important point in Theo’s discussion is the difference between producing more code and delivering more value.

AI can generate functions, tests, components, database queries, and entire features. It can also produce a large pull request in a relatively short amount of time.

However, someone still needs to determine whether that code solves the right problem, fits the existing architecture, handles edge cases, and behaves correctly under real conditions.

Writing code has never been the only difficult part of software engineering.

Understanding requirements, making architectural decisions, reviewing changes, testing behaviour, maintaining existing systems, and diagnosing production failures can consume considerable time.

AI may reduce the time needed for implementation while increasing the amount of code that needs to be understood and reviewed.

If a developer produces changes faster than a team can reasonably review them, the apparent productivity improvement may create a different bottleneck.

The situation becomes more concerning when expectations increase because AI is available, but the time allocated for testing, review, and maintenance remains unchanged.

And when something breaks in production, the responsibility does not necessarily disappear just because AI generated the code.

The engineer is still expected to understand the system, investigate the failure, and help restore it.

This is why I believe AI-assisted development should be evaluated by the quality and usefulness of the resulting software, not simply by how quickly code appears on the screen.

3. The Modern Engineer Is Expected to Do More Than Engineering

Theo also discusses how the expectations placed on engineers continue to expand.

In addition to writing software, engineers may be expected to understand product strategy, user experience, business requirements, infrastructure, security, compliance, and operational concerns.

There is nothing inherently wrong with understanding these areas. In fact, a broader understanding can make an engineer considerably more effective.

The difficulty arises when the expected range of responsibilities grows while the time available to learn, practise, and develop expertise becomes shorter.

Engineers are increasingly encouraged to take ownership of an entire product or system rather than focusing on implementation alone.

That can be valuable, especially in small teams. However, there is a difference between encouraging people to develop broader skills and expecting one person to compensate for every missing role in an organisation.

AI can help individuals work across unfamiliar areas, but assistance does not automatically replace expertise, sound judgement, or accountability.

The challenge is finding a sustainable balance between versatility and unrealistic expectations.

4. What Happens When the Junior-Level Learning Path Disappears?

Perhaps the most concerning part of Theo’s discussion is the potential impact of AI on junior developers.

Traditionally, junior engineers gain experience through relatively small tasks: fixing bugs, improving existing features, writing tests, handling simple requirements, and learning how an established codebase works.

These tasks are not merely inexpensive work for a company. They are also opportunities to develop professional judgement.

Over time, developers learn how to investigate unfamiliar systems, recognise fragile code, communicate technical trade-offs, and understand the consequences of their decisions.

AI creates a potential disruption to this process.

If a senior engineer with AI assistance can complete tasks that previously went to junior developers, a company may decide that hiring additional juniors is less attractive.

From an individual company’s short-term perspective, that decision might appear economically reasonable.

Across the industry, however, the consequences could be more complicated.

If fewer juniors are hired and fewer people receive opportunities to learn through real engineering work, where will the next generation of experienced engineers come from?

Senior engineers do not appear fully formed. They become senior by accumulating experience, making mistakes, receiving feedback, and gradually taking on greater responsibility.

AI might accelerate some parts of that journey, but it cannot guarantee that the industry will continue providing enough opportunities for people to develop the judgement required to maintain complex systems.

This is a structural concern rather than an argument that AI should not be used.

5. Two Different Directions: Product Engineering and Systems Engineering

Theo also describes two broad patterns of engineering work that may become increasingly relevant.

These are useful conceptual categories, not necessarily formal job titles.

Product-oriented engineering focuses on identifying problems, validating ideas, building minimum viable products, and iterating quickly based on user feedback.

The goal is to discover whether a solution is useful before investing heavily in it.

Systems-oriented engineering focuses on improving systems that have already demonstrated value. This may involve reliability, performance, scalability, architecture, operational efficiency, and the careful management of complexity.

The distinction matters because building the first version of a product and operating a successful product at scale are different challenges.

A small business validating a new service may not need the same architecture as a platform serving millions of users. Conversely, a system with demanding reliability requirements cannot be treated like a disposable prototype.

AI may be useful in both areas, but the engineering decisions remain different.

For me, this distinction is a reminder that there is no single development workflow or architectural approach that makes sense for every business.

The right solution depends on the problem, the risks, the available resources, and the stage of the product.

6. Theo Is Not Simply Saying That Nobody Should Become a Programmer

It is important not to misinterpret the message.

Theo acknowledges that he uses AI himself and recognises that he is part of the broader ecosystem influencing how people think about software development.

His criticism is not simply that AI is bad or that developers should return to writing everything manually.

The deeper concern is the way the industry responds to AI.

When demonstrations of rapid development become promises of dramatically increased productivity, organisations may raise expectations without adequately accounting for testing, review, maintenance, and the complexity of real systems.

The benefits of AI may be real, while the expectations built around those benefits can still become unreasonable.

Theo’s conclusion is not a straightforward instruction to avoid programming. It is closer to recognising that the profession is changing and that engineers must decide how they want to adapt to that change.

I agree that this is a difficult question, particularly for people who are still trying to establish themselves in the industry.

But I also think there is another question worth asking:

Do we all need to pursue the same version of a software engineering career?

7. My Perspective: I Would Rather Help SMEs Solve Real Problems

After considering these points, I find myself increasingly interested in building software and digital solutions for small and medium-sized enterprises rather than making a corporate engineering career my primary goal.

This does not mean that I believe all large companies are bad places to work. Nor does it mean that independent work is automatically better.

There are excellent engineering teams in large organisations, with healthy collaboration, realistic expectations, good mentoring, and strong technical practices. There are also poorly managed companies where hierarchy, office politics, and excessive workloads make otherwise interesting work difficult.

Independent work has its own problems, including unpredictable income, difficult clients, unclear requirements, and the need to manage sales and operations in addition to development.

Neither path is free of trade-offs.

What matters to me is the environment in which I can do useful work, make decisions responsibly, and maintain a reasonable degree of control over how that work is delivered.

Working with SMEs offers a different kind of relationship

Small businesses often have practical problems that do not require unnecessarily complicated solutions.

A WooCommerce store may have a slow checkout process. A business may be spending money on advertising without understanding which campaigns produce actual customers. A team may be managing repetitive administrative tasks manually because nobody has built a suitable internal tool.

These are not necessarily glamorous engineering challenges. They can nevertheless have a direct effect on a business.

My interest is in identifying these problems and building solutions that are appropriate for the business's actual needs and resources.

Sometimes that might mean improving an existing WordPress installation rather than replacing it.

Sometimes it might mean simplifying a checkout flow, fixing analytics, automating a repetitive task, or building a small application.

And sometimes the best technical decision might be not to build anything new at all.

For an SME, spending money on a sophisticated architecture that solves no meaningful business problem is not a sign of engineering excellence.

Good engineering should be measured partly by whether it solves the right problem at a cost the business can sustain.

The difference is not that SMEs are always easier

I do not want to romanticise independent work or suggest that every small business owner is easy to work with.

SMEs can have unrealistic expectations, unclear priorities, limited budgets, and clients who constantly change their requirements.

The difference I am looking for is the possibility of having a more direct relationship between the person who needs a solution and the person who builds it.

In an ideal client relationship, the business explains its problem, we discuss the available options, agree on a scope and budget, and decide whether working together makes sense.

If the expectations are realistic and the collaboration is healthy, we proceed.

If the expectations are unreasonable, the scope cannot be agreed upon, or the working relationship is clearly incompatible, I can decline the project.

My informal rule is simple: if the collaboration makes sense, let's build something useful. If it does not, there is no need to force it.

Of course, this freedom is not absolute. Independent developers still need income, and turning down work can have financial consequences. Finding good clients is itself a skill that requires time to develop.

Nevertheless, I value having more control over which problems I accept and which working relationships I pursue.

Corporate hierarchy is a different constraint

In a company, engineers operate within an organisational structure.

Managers determine priorities, leadership allocates resources, and organisational hierarchies influence which decisions can be challenged or changed.

A healthy company can use this structure effectively. Experienced leaders can provide direction, remove obstacles, support junior employees, and help teams make better decisions.

The problem arises when authority becomes a substitute for sound reasoning.

A deadline may be unrealistic, but challenging it could be interpreted as a lack of commitment. A technical concern may be dismissed because it comes from someone with less seniority. A team may be expected to deliver more without receiving the time or resources needed to do so.

In such an environment, the engineer's ability to make technically responsible decisions can be limited by organisational dynamics.

This is the aspect that makes me cautious about pursuing a corporate engineering career as my primary objective.

I do not want to spend my working life trying to satisfy expectations that are disconnected from the actual work, particularly when those expectations are reinforced by hierarchy rather than constructive collaboration.

That does not mean every company operates this way. It means that the quality of the working environment matters just as much as the job title.

If I ever join a company, I would want to evaluate how it treats engineers, handles disagreements, sets deadlines, and responds when things go wrong—not simply its reputation or size.

8. AI Should Help Us Deliver Better Solutions, Not Just More Work

My position on AI is practical.

I use AI to help build software, explore approaches, understand unfamiliar concepts, and accelerate implementation. I do not believe using AI makes the work illegitimate.

However, generating code is not the same as taking responsibility for a finished application.

A developer still needs to understand the requirements, evaluate the proposed implementation, test the result, recognise uncertainty, and be honest about what they can support.

For an independent developer serving SMEs, AI can be particularly useful because time and resources are limited.

It may help one person accomplish work that would otherwise require considerably more manual effort. That can make certain solutions more accessible to businesses with modest budgets.

But the objective should not be to accept an unlimited amount of work simply because AI makes implementation faster.

If AI saves two hours on a task, those hours can be used for testing, better communication, documentation, learning, or simply keeping the project within a sustainable schedule.

The benefit should not automatically become an excuse to double the workload.

I also have concerns about exaggerated AI marketing that suggests anyone can become an experienced engineer almost overnight or that an AI-generated demonstration proves a person is ready to manage complex production systems.

AI can lower barriers to building software. It does not eliminate the need to learn, exercise judgement, or understand the consequences of technical decisions.

We should be able to acknowledge both its genuine benefits and its limitations.

9. This Is a Career Preference, Not a Declaration That Corporate Engineering Is Dead

I want to make one thing clear: I am not claiming that becoming an engineer at a large company is a bad decision.

For many developers, a well-managed engineering organisation can provide excellent mentorship, exposure to complex systems, collaboration with experienced colleagues, stable income, and opportunities that would be difficult to obtain independently.

Those benefits matter.

My preference is simply to prioritise a different path for now.

Rather than making a corporate engineering title the ultimate measure of success, I want to focus on using software to solve real problems for businesses that need help with digitalisation.

I can still learn from open-source projects, study system design, improve my testing practices, build applications, and collaborate with other developers.

I can also continue developing my own projects while learning what it takes to turn software into something useful and sustainable.

None of those activities requires me to pretend that I have experience I do not possess. Equally, not having worked at a large technology company does not mean that the skills I have developed through building software are worthless.

The important thing is to be honest about my experience, recognise my limitations, and continue improving through real work.

Perhaps I will eventually find a company whose engineering culture suits me. If that opportunity appears, I can evaluate it on its merits.

For now, I would rather build a career around the problems I want to solve than spend too much energy trying to prove that I belong to a particular category of engineer.

Final Thoughts

Theo's discussion made me think more carefully about the relationship between AI, engineering expectations, and the future of the profession.

The most important lesson I took from it is not that programming is no longer worth pursuing.

It is that the environment in which we build software matters.

AI can make implementation faster, but faster implementation does not automatically create better products, healthier teams, or more sustainable working conditions.

Companies still need realistic expectations. Engineers still need opportunities to learn. Software still needs to be tested, maintained, and operated responsibly.

And developers do not all have to pursue the same career path.

For me, building solutions for SMEs is an appealing direction because it brings software development closer to practical business problems and gives me the opportunity to choose projects and working relationships more deliberately.

There will still be difficult clients, financial uncertainty, and plenty of technical challenges. I am not expecting an easy path.

I simply want to build useful things, help businesses make better use of technology, and develop a sustainable way to keep doing work that I genuinely enjoy.

Perhaps the goal is not to become the kind of engineer the industry happens to reward at a particular moment. Perhaps it is to become a developer who can consistently turn real problems into useful, maintainable solutions.

And if AI can help me do that more effectively, I intend to use it—without forgetting that the responsibility for the work remains mine.

This article is a personal reflection inspired by Theo's discussion on VoidFnC. The observations attributed to him are my interpretation of the video's themes, not a claim that every point represents a universally established industry fact. My own conclusions about working with SMEs reflect my preferences and priorities, rather than a claim that independent work is inherently better than employment.

Why Convention over Configuration Still Matters in 2026?

Joni Ilman Pahmi — Thu, 01 Oct 2026 23:31:53 +0000

Software development is full of decisions.

Where should a file live? How should a route be registered? Which configuration file connects a model to a database table? Where should API endpoints be defined? Which tools need to be wired together before the application can even start?

Not all of these decisions create business value.

This is where Convention over Configuration (CoC) becomes useful.

Convention over Configuration is a software design approach that reduces the amount of configuration developers need to write by establishing sensible, predictable defaults. Instead of explicitly describing every relationship between components, the framework assumes a standard structure and lets developers override that behaviour when their application needs something different.

The idea became particularly well known through Ruby on Rails and its “convention over configuration” philosophy.

The important part is not that configuration disappears.

The important part is that developers are no longer required to configure things that already follow an obvious convention.

The Problem with Too Much Configuration

Imagine creating a new page.

In a heavily configuration-driven architecture, adding that page might involve creating the component itself, registering a route, updating another configuration file, and possibly modifying additional metadata.

The page is new. The route is new.But the relationship between them is already obvious. A framework can reasonably infer:

This file represents a page, therefore it should become a route.

That removes a decision without removing control. The same idea can apply to APIs, database models, application structure, testing, and many other parts of a project.

1. Faster Development

The most obvious benefit of conventions is that developers write less infrastructure code. Suppose a framework knows that files inside a particular directory represent application pages. Creating a new page becomes as simple as creating a file.

Solid-Vue follows this approach with file-based routing. A file such as:

src/pages/about.vue

automatically becomes:

/about

Nested directories and dynamic filenames follow the same convention.

src/pages/
├── index.vue
├── about.vue
└── users/
    └── [id].vue

This produces routes without maintaining a large manual routing configuration. The project structure becomes part of the routing system itself. That may look like a small convenience.

Across hundreds of routes and multiple developers, however, removing repeated configuration becomes a meaningful productivity improvement.

2. Less Boilerplate and Less Ceremony

Configuration has a cost.

Even when each configuration change takes only a few minutes, developers still have to remember where it belongs, how it is structured, and which other configuration files must be updated.

That creates cognitive overhead.

Convention-based frameworks move common decisions into the framework itself.

Solid-Vue applies this principle beyond frontend routing.

For example, API handlers can live inside:

src/server/api/

The framework scans this directory and derives routes from the file structure.

A file such as:

src/server/api/products/[id].ts

can represent a dynamic API endpoint without requiring a separate route registration file. The developer writes the endpoint. The framework handles the repetitive wiring.

3. A Predictable Project Structure

Conventions also make unfamiliar projects easier to understand.

A predictable structure means developers spend less time asking:

Where does this belong?

Solid-Vue establishes several conventional locations:

src/
├── components/
├── pages/
├── layouts/
├── stores/
└── server/
    └── api/

Some of these directories are conventions rather than strict requirements, while pages and server/api are actively scanned by the framework.

This distinction matters.

Good conventions should provide structure without turning the framework into a prison.

Developers should know where things normally go, while still being able to organise their own application when necessary.

4. Convention Does Not Mean No Configuration

One of the biggest misunderstandings about Convention over Configuration is that it means configuration is bad.

It does not.

Configuration becomes valuable when the default behaviour is no longer appropriate.

For example, suppose the convention says:

src/pages/about.vue → /about

That is useful because most applications do not need to explain that relationship manually.

But when an application requires something unusual, explicit configuration should still be available.

This is where a good framework should provide an escape hatch.

Solid-Vue describes this philosophy directly:

Reduce configuration, not capability.

Its configuration layer provides sensible defaults while keeping the underlying Vue, Vite, Vue Router, Pinia, and H3 APIs accessible.

That distinction is important.

The goal is not to hide the underlying ecosystem.

The goal is to avoid making developers configure things that can already be reasonably inferred.

5. Conventions Make Frameworks Easier to Learn

Convention also creates a shared mental model.

When every project invents its own architecture, developers must learn the architecture before they can effectively work on the application.

When a framework establishes common conventions, knowledge becomes transferable.

A developer who already understands the framework can open another project and immediately recognise familiar patterns.

This does not eliminate the learning curve.

In fact, conventions can introduce their own form of complexity: developers need to understand what the framework assumes and how those assumptions work.

The difference is that the complexity is learned once and then reused across projects.

6. Less Configuration Can Mean Less Configuration Churn

Large configuration files often become another part of application maintenance.

Every new feature may require another entry.

Every renamed component may require another update.

Every new API endpoint may require another registration.

With convention-based systems, some of these relationships are derived directly from the source structure instead.

That can reduce repetitive configuration changes and, as a consequence, reduce one potential source of configuration drift and merge conflicts.

It is not a guarantee that merge conflicts disappear.

It simply means there are fewer places where developers need to manually maintain the same information.

The source code becomes the source of truth.

Convention vs Configuration

Convention and configuration are not opposing philosophies where one must completely replace the other.

They are better understood as a balance.

Approach	Strength	Trade-off
Convention	Fast setup, predictable structure, less boilerplate	Framework rules can feel “magical”
Configuration	Explicit control and visibility	More boilerplate and maintenance
Hybrid	Sensible defaults with explicit escape hatches	Requires good framework design

Pure convention can become frustrating when developers cannot understand or override what the framework is doing.

Pure configuration can become exhausting when developers have to describe every relationship manually.

The useful middle ground is:

Use conventions for the common path. Use configuration for the exceptional path.

Why This Matters for Small and Growing Applications

This becomes especially relevant for small teams and growing businesses.

Most applications do not need every architectural decision to become a project of its own.

A team should be able to create a page, add an API endpoint, manage application state, and deploy an application without repeatedly designing infrastructure around those actions.

This is one of the reasons Solid-Vue is built around existing Vue ecosystem tools instead of replacing them.

Vue remains Vue.

Vite remains Vite.

Vue Router remains accessible.

Pinia remains accessible.

H3 remains accessible.

Solid-Vue simply establishes conventions and defaults around them so developers spend less time wiring the ecosystem together.

That philosophy can be seen throughout the framework: file-based pages, file-based server routes, pre-wired Pinia, conventional project structure, CLI-based project creation, and automated build/deployment workflows.

The Real Value of Convention over Configuration

Convention over Configuration is not really about writing fewer lines of code.

It is about making fewer unnecessary decisions.

A developer's time is valuable.

Instead of repeatedly deciding:

where routes should be registered,
how API files should be connected,
how common tools should be wired,
or which configuration file needs another entry,

the framework can provide a predictable answer.

That lets developers spend more of their attention on the part that actually differentiates the application: the business logic, user experience, and product itself.

Good conventions should therefore feel almost boring.

You create the file.

You follow the structure.

The framework understands what you mean.

And when the default is no longer enough, configuration is still there.

That is the real idea behind Convention over Configuration:

less configuration where convention is enough, without sacrificing control when convention is not enough.

Solid-Vue Adds Per-Page Layouts and Its First UI Kit Add-on: Octans UI

Joni Ilman Pahmi — Thu, 01 Oct 2026 09:20:44 +0000

Solid-Vue is getting another small but important step toward making application structure easier to manage.

This release introduces two additions:

Per-page layouts, powered by Vue Router's definePage().
Octans UI add-on, our first integration with a UI component library.

They solve different problems, but they share the same goal: giving Solid-Vue applications more structure without making developers build and configure everything from scratch.

Per-Page Layouts

Not every page in an application should look the same.

A dashboard might need a persistent sidebar and navigation. An authentication page might need a simple centred card. A public page might use an entirely different shell.

Previously, developers had to decide how to structure those layouts themselves. Solid-Vue can now handle that part with a simple convention.

Create layout components inside src/layouts:

<!-- src/layouts/dashboard.vue -->
<template>
  <div class="dashboard-shell">
    <nav>
      <!-- Dashboard navigation -->
    </nav>

    <main>
      <slot />
    </main>
  </div>
</template>

You can also keep a default layout:

<!-- src/layouts/default.vue -->
<template>
  <main class="default-layout">
    <slot />
  </main>
</template>

Then wrap your application's router once in App.vue:

<script setup lang="ts">
import { SolidVueLayout } from 'solid-vue/client'
</script>

<template>
  <SolidVueLayout>
    <RouterView />
  </SolidVueLayout>
</template>

Individual pages can then request the layout they need:

<script setup lang="ts">
definePage({
  meta: {
    layout: 'dashboard',
  },
})
</script>

<template>
  <h1>Dashboard</h1>
</template>

That's it.

Pages that don't specify a layout automatically use src/layouts/default.vue.

This means layout selection stays close to the page itself instead of requiring another routing configuration file.

Why `definePage()`?

One important detail here is that definePage() isn't a Solid-Vue-specific API.

It comes from the Vue Router ecosystem and is already familiar to developers using file-based routing with Vue Router tooling.

Solid-Vue simply uses the page metadata to connect the route to the corresponding layout.

For example:

definePage({
  meta: {
    layout: 'auth',
  },
})

maps naturally to:

src/layouts/auth.vue

The convention keeps the amount of configuration small while still allowing applications to grow beyond a single application shell.

Layouts Are About More Than Visuals

A layout isn't necessarily just a collection of CSS classes.

It can represent an application's structural boundary.

For example, a typical application might eventually have:

src/
├── layouts/
│   ├── default.vue
│   ├── auth.vue
│   └── dashboard.vue
│
├── pages/
│   ├── index.vue
│   ├── login.vue
│   ├── register.vue
│   └── dashboard/
│       ├── index.vue
│       └── settings.vue

The pages remain focused on their own content, while layouts handle the surrounding application structure.

That separation becomes particularly useful when an application has several sections with different navigation, headers, or visual shells.

Our First UI Kit Add-on: Octans UI

The second addition in this release is a new Solid-Vue add-on for Octans UI.

Install it with:

npx solid-vue add octans-ui

This is the first time one of our add-ons integrates a UI component library rather than simply adding a development utility or configuration.

The goal is the same as with the rest of the Solid-Vue add-on system: reduce the amount of repetitive setup required when starting a project.

What Does the Add-on Do?

Octans UI requires a small amount of application-level setup.

The Solid-Vue add-on takes care of that wiring for you.

In particular, it:

Installs the required Octans UI package.
Adds the UiProvider integration to App.vue.
Registers the Octans UI plugin in main.ts.
Leaves the application ready to import and use Octans UI components.

For example:

<script setup lang="ts">
import { Button, Card } from '@octans/ui'
</script>

<template>
  <Card title="Hello">
    <Button primary>
      Click me
    </Button>
  </Card>
</template>

The important part isn't that installing a UI library is difficult.

It isn't.

The point is that these small integration steps are exactly the kind of setup that tends to get repeated across projects.

Solid-Vue's add-on system gives us a place to automate them.

We Don't Want the CLI to Guess

There is another detail we're particularly careful about.

A CLI that modifies an existing project needs to know when it can safely make an automatic change — and when it can't.

For example, the add-on can normally update App.vue and main.ts when they follow the expected structure.

But developers are free to customise those files.

If Solid-Vue can't confidently determine where an integration should be added, the add-on doesn't try to make a risky modification.

Instead, it reports what needs to be added manually.

That's intentional.

We'd rather give you a clear instruction than silently produce a broken application.

Using Layouts and Octans UI Together

These two features were also tested together.

A typical application can have a layout responsible for the application shell while Octans UI provides the components used inside it.

For example:

Application
│
├── SolidVueLayout
│   │
│   ├── Dashboard Layout
│   │   ├── Navigation
│   │   ├── Header
│   │   └── RouterView
│   │       │
│   │       └── Octans UI components
│   │
│   └── Other Layouts
│
└── Vue Router

The layout controls the surrounding structure.

The router controls which page is displayed.

Octans UI provides reusable interface components.

Each part has a relatively small responsibility, without requiring a large application architecture just to get started.

We tested this combination in both development and production builds, including a layout wrapping the UI provider and router.

The result is the same workflow you'd expect from a normal Solid-Vue application.

Getting Started

If you're starting a new project, create one with:

npm create solid-vue@latest my-app

Then:

cd my-app

And add Octans UI:

npx solid-vue add octans-ui

You can then create your layouts under:

src/layouts

and select them from individual pages with:

<script setup lang="ts">
definePage({
  meta: {
    layout: 'dashboard',
  },
})
</script>

What's Next?

We're keeping Solid-Vue's approach deliberately incremental.

Rather than adding every possible feature to the framework, we're looking for the repetitive pieces that developers commonly need when building small and growing applications.

Layouts are one of those pieces.

UI library integration is another.

The add-on system gives us room to experiment with more integrations without making every Solid-Vue project depend on everything.

And this is only the beginning of that approach.

Try It

Create a new Solid-Vue application:

npm create solid-vue@latest my-app
cd my-app

Then add Octans UI:

npx solid-vue add octans-ui

For more information, see the documentation:

Solid-Vue is still in early access, so we'd love to hear what feels useful, what feels rough, and what you'd like to see next.

Try it, build something small, and let us know what you think.

See: Solid-Vue Adds Per-Page Layouts and Its First UI Kit Add-on: Octans UI

Why I Built Solid-Vue JS: File-Based API Routing for Vue + Vite

Joni Ilman Pahmi — Wed, 30 Sep 2026 03:31:45 +0000

Quick note: Solid-Vue JS is not SolidJS. It's a Vue + Vite framework. Yes, the names are close, and I'm sorry for the confusion! 🙂

The itch

Vue + Vite is a fantastic frontend setup. But the moment a project needs even a small API (a form handler, a webhook, a tiny CRUD), I found myself standing up a separate server or pulling in a much bigger framework than the project needed.

The idea started with a small project: I wanted to build a mini ERP for a friend's cilok goang shop using Vue on the frontend and a vanilla JavaScript backend.

I started with plain Vue + Vite, expecting it to be straightforward. Instead, I kept running into the usual setup friction — version conflicts, Vite configuration issues, routes returning 404s, and all the little pieces that need to be wired together manually. I eventually tried Nuxt because so much of that structure is already built in, but that came with its own friction too, including issues while setting up shadcn-vue and a project scaffold that felt surprisingly slow for such a small project.

That experience made me think there should be a middle path: keep Vue + Vite as the foundation, but provide enough conventions and tooling that I don't have to rebuild the same project structure every time.

I wanted a middle path: keep Vue + Vite as the foundation, and add just enough structure for the backend side to live in the same project.

What Solid-Vue JS is

Solid-Vue JS is a meta-framework built around a custom Vite plugin. Its core idea is file-based API routing on top of h3: you create a file, and it becomes an API endpoint.

It ships as three npm packages:

solid-vue: the core framework
create-solid-vue: project scaffolding
solid-vue-cli: in-project commands for add-ons

Getting started

npm create solid-vue@latest my-app
cd my-app
npm install
npm run dev

File-based API routes

Solid-Vue JS uses conventions to keep application structure predictable. Two of these — pages and server/api — are scanned automatically by the framework. The rest are suggested patterns for organising your own code.

├── src/
│   ├── App.vue
│   ├── main.ts
│   ├── components/
│   ├── pages/           # file-based routing
│   ├── layouts/         # page layouts — see Routing
│   ├── stores/
│   └── server/
│       └── api/         # file-based routing
├── public/              # Static assets, served as-is
├── index.html
└── vite.config.ts

Add-ons from the CLI

Instead of hand-wiring config every time, add-ons install and configure themselves:

npx solid-vue add tailwind

Right now the add-ons are Tailwind CSS, Lucide icons (lucide-vue-next), and Tabler icons (@tabler/icons-vue).

Deploying

I've tested a real project end-to-end: it builds cleanly and deploys to Cloudflare Workers with wrangler. There is no Cloudflare-specific configuration required by Solid-Vue JS — deployment is handled with a single command. The only prerequisite is authenticating Wrangler with your Cloudflare account first with npx wrangler login. If you done with Wrangler Auth, you can deploy your project to Cloudflare Worker with one command: npm run deploy -- --target=cloudflare-worker.

Where it stands

Solid-Vue JS is early access / beta. The core works, the packages are on npm, and the docs are live, but I expect rough edges, and that's exactly why I'm posting this.

🌐 Landing page: https://solid-vue.tech
📚 Docs: https://docs.solid-vue.tech
💻 GitHub: https://github.com/solid-vue/solid-vue/

Some ideas I'm exploring for later (no promises or timelines): REST connectors for other backends and integrations with services like Firebase and Supabase.

I'd love your feedback

If you try it, I want to know:

What broke or confused you in the first 10 minutes?
What's the one feature that would make you actually use it?

Drop a comment below. I read and reply to every one. Thanks for reading! 🙏

What Is the Simplest Frontend Framework for a Full-Stack Developer in 2026?

Joni Ilman Pahmi — Tue, 29 Sep 2026 09:38:17 +0000

If you already know JavaScript, HTML, CSS, Node.js, and some backend development, choosing a frontend framework in 2026 can feel strangely difficult.

The syntax is rarely the hardest part.

You also have to think about routing, state management, API integration, project structure, deployment, documentation, ecosystem, community, and—if you're looking for work—the size of the job market.

So a very practical question appears:

Which frontend framework is the simplest to learn while still being practical for full-stack applications?

The problem is that "simple" can mean different things.

It can mean fewer lines of code.
It can mean fewer concepts.
It can mean less configuration.
It can mean faster development.
Or it can simply mean that the architecture makes sense to you.

Those are not always the same thing.

This article compares React with Vite, Next.js, Vue, Svelte, and a more opinionated Vue + Vite approach from the perspective of a developer who already understands JavaScript and backend development.

What Does "Simple" Actually Mean?

For a full-stack developer, simplicity is not just about component syntax.

A framework might be considered simple when you can:

get a project running quickly;
understand the project structure without learning dozens of conventions;
add routing without a lot of configuration;
connect the frontend to an API without fighting the framework;
manage application state with a predictable solution;
deploy without understanding a large platform-specific abstraction;
come back to the project six months later and still understand it.

That last point is often overlooked.

A framework can be easy to start with but difficult to maintain.

Another framework can provide a huge number of features out of the box but require more concepts before you feel comfortable.

So instead of asking:

Which framework is the best?

A more useful question is:

Which level of abstraction matches the application I'm building?

That changes the entire discussion.

React + Vite

React remains a familiar choice for frontend development, while Vite provides a straightforward development environment for React applications.

For developers who already know React, this combination can have a very small immediate learning curve.

You already understand components, state, props, events, asynchronous code, and the general React development model.

The trade-off appears when you move from components to the application as a whole.

React itself is a UI library rather than an all-in-one application framework. Depending on your project, you may need to make additional decisions about routing, state management, forms, data fetching, validation, and other application concerns.

That's not necessarily a bad thing.

Experienced developers may actually prefer this flexibility because they can choose exactly what they need.

But if your goal is:

"I want a straightforward application workflow with sensible defaults."

then every additional decision becomes part of the learning curve.

So the interesting distinction is:

React can be simple at the component level while the surrounding application architecture remains your responsibility.

Next.js

Next.js provides a broader application framework around React.

It brings conventions and features for things such as routing, server-side capabilities, rendering strategies, and deployment-oriented workflows.

That can reduce the amount of infrastructure you have to assemble manually.

But convenience has another side.

You're not only learning React.

You're also learning the Next.js way of handling routing, rendering, server functionality, data access, caching, and project organisation.

For developers who want a full-stack React framework, that can be exactly what they're looking for.

But for someone whose main goal is learning frontend development as quickly as possible, those additional concepts are worth considering.

This creates an important distinction:

More built-in capability can reduce manual wiring, but it can also increase the framework mental model.

Vue

Vue takes a slightly different approach to the learning experience.

Its component model is approachable for developers who already understand HTML, CSS, and JavaScript, while the official ecosystem provides established solutions for common application concerns.

That gives Vue an interesting middle ground.

You can start with a relatively small application and gradually introduce routing, state management, and other capabilities as the project grows.

You don't necessarily need to adopt a complete application platform on day one.

For small applications, that incremental approach can be useful.

It allows the developer to learn the framework itself first, then add more pieces when the application actually needs them.

In other words:

Vue can provide structure without forcing the entire application architecture on you immediately.

Svelte

Svelte is another option that often comes up when simplicity is the main objective.

Its component syntax can feel concise, and its compiler-oriented approach moves some work into the build process rather than relying on a large runtime abstraction.

That can make the development experience feel different from React or Vue.

However, fewer lines of code do not automatically mean a smaller learning curve.

A developer coming from React still needs to understand Svelte's component model, conventions, and ecosystem.

So Svelte is worth evaluating on its own terms rather than simply assuming:

fewer lines = simpler framework.

Sometimes the mental model matters more than the amount of code you write.

Full-Stack Developers Have a Different Problem

A full-stack developer already understands concepts such as:

HTTP;
APIs;
authentication;
databases;
server-side validation;
application architecture.

That means the frontend framework does not exist in isolation.

It has to fit into an existing mental model.

There are generally two ways to structure the application.

The first is to keep the frontend and backend separate:

Browser
   |
   v
React / Vue / Svelte
   |
   v
REST / GraphQL API
   |
   v
Node / Laravel / Other backend
   |
   v
Database

The second is to use a framework that combines frontend and server capabilities:

Browser
   |
   v
Full-stack framework
   |
   +---- UI
   |
   +---- Server / API
   |
   +---- Data access
   |
   v
Database

Neither architecture is automatically simpler.

The important question is whether the framework's conventions actually reduce the amount of work required for your particular application.

The Hidden Cost of "Simple"

Every abstraction has a learning cost.

A framework might give you routing, server functions, data fetching, caching, rendering strategies, and deployment conventions.

Those capabilities can save time later.

But every one of those features also creates another concept you need to understand.

This creates a trade-off:

More built-in capability
        |
        v
Less manual wiring
        |
        v
More framework concepts

And the opposite direction looks like this:

Less built-in capability
        |
        v
More manual choices
        |
        v
Smaller framework mental model

Neither side is universally correct.

The sweet spot depends on the project.

A Small Business Application Is Not a Large Platform

Consider a typical small-business application.

It might need:

authentication;
a dashboard;
CRUD operations;
forms;
an API;
database access;
reports;
PDF or spreadsheet exports;
a few charts.

That's already a real application.

But it does not necessarily require the architecture of a large distributed platform.

Sometimes a predictable set of conventions is more useful than a large collection of infrastructure designed for problems the application does not currently have.

This is where lightweight application architecture becomes interesting.

The goal isn't to remove capabilities.

The goal is to avoid making developers configure capabilities that their application doesn't actually need yet.

Where a Lightweight Vue + Vite Approach Fits

This is also the idea behind Solid-Vue.

Solid-Vue is an early-access Vue + Vite application framework focused on small and growing applications.

The basic idea is straightforward:

Keep Vue and Vite as the foundation, then provide sensible defaults and integrated pieces for common application development tasks.

For example, a project can bring together:

Vue;
Vite;
file-based routing;
Pinia;
a server layer.

The point is not to replace Vue.

The point is to reduce the amount of orchestration work around Vue.

Instead of repeatedly deciding how to connect the common pieces together, the framework provides a starting structure for developers who want a more opinionated workflow.

For a full-stack developer building business applications, that can be a useful distinction.

At the same time, Solid-Vue is still early-access.

That means there is less ecosystem maturity than established technologies such as React, Next.js, Vue, or Svelte.

That's an important trade-off, especially if your priority is ecosystem size, tutorials, community support, or hiring opportunities.

What About Jobs and Community?

Learning difficulty is only one variable.

If your goal is employment, you should also consider the technologies actually requested by employers in the market where you want to work.

A smaller framework might be pleasant to learn while having fewer job listings, tutorials, or developers available to help.

A larger ecosystem can provide more resources and potentially more employment opportunities.

At the same time, job availability depends on many other factors, including country, company, seniority, and your overall skill set.

So choosing a framework based only on the word "simple" can be misleading.

A practical way to think about it is to separate your goals.

If your priority is employment, investigate the technologies employers are actually asking for.

If your priority is learning frontend fundamentals, choose a framework whose programming model you can understand and practise consistently.

If your priority is building small full-stack applications, evaluate how much application wiring the framework requires for the kinds of projects you actually expect to build.

Different priorities can lead to different choices.

Should You Stay With React or Switch?

If you already know React and have built several projects, switching is not automatically necessary.

Your existing knowledge still transfers.

Components, state, props, events, asynchronous operations, browser behaviour, JavaScript, and application architecture are not concepts that disappear when you change frameworks.

In fact, you don't have to turn framework selection into a permanent decision.

A better experiment is to build the same small application using two different frameworks.

For example:

Customer Management
       |
       +-- Search
       +-- Add customer
       +-- Edit customer
       +-- Delete customer
       +-- API
       +-- Database

Build it with the framework you already know.

Then build the same application with Vue or Svelte.

Now compare the development experience.

Don't only count lines of code.

Ask:

How long did the first working version take?
How many dependencies did you add?
How many configuration decisions did you make?
How often did you need the documentation?
How easy was routing?
How easy was API integration?
How easy was state management?
Could you explain the architecture to another developer?
Would you still understand the project six months later?

Those answers tell you much more than a generic claim that one framework is "easier".

So, Which One Is the Simplest?

There isn't one framework that is objectively the simplest for every developer.

For someone already comfortable with React, React + Vite may have the smallest immediate learning cost.

Next.js provides a more integrated full-stack React experience, but that also introduces additional framework concepts.

Vue offers an approachable component model and an ecosystem where application capabilities can be introduced progressively.

Svelte provides a distinct and concise development model, but still requires learning its own ecosystem and conventions.

A lightweight Vue + Vite framework such as Solid-Vue takes another approach: add more conventions around Vue while keeping the underlying stack relatively familiar.

So the more useful question isn't:

"Which framework is objectively easiest?"

It's this:

"Which framework gives me the least unnecessary complexity for the applications I actually want to build?"

For a full-stack developer, that's a much more practical question.

And when you're still unsure, there's a simple way to find out:

Build one small application with two candidates.

The development experience will probably tell you more than another twenty framework comparison articles.

Why Small Businesses Rarely Need Heavy JavaScript Frameworks??

Joni Ilman Pahmi — Sun, 06 Sep 2026 06:44:59 +0000

Small and medium-sized enterprises (SMEs/SMBs) rarely need heavy enterprise JavaScript frameworks for their business websites.

Frameworks such as Angular, React, or complex meta-frameworks such as Next.js are incredibly capable. They are designed to solve serious problems: complex application state, large data flows, sophisticated user interfaces, and development at significant team scale.

But a typical small-business website has a very different job.

It needs to load quickly, communicate clearly, generate leads, support business operations, and remain reliable for years.

In other words, the priorities are usually speed, clarity, and reliability—not massive multi-team scaling.

This difference is easy to overlook, especially when modern JavaScript tooling makes it tempting to reach for the most powerful stack available.

That can create what developers sometimes call a "complexity tax."

Why Heavy Frameworks Can Be Overkill for SMB Websites

The problem isn't that enterprise frameworks are bad. The problem is using enterprise-level engineering solutions for problems that don't require them.

Factor	Enterprise JavaScript Applications	Typical SMB Websites
Primary goal	Highly dynamic application state and heavy data pipelines	Fast loading, clear business information, and simple lead capture
SEO & performance	Often involves significant client-side JavaScript and hydration complexity	Prefer fast, server-rendered HTML that search engines can easily understand
Development cost	Can require specialized developers familiar with complex state, build, and deployment systems	Lower upfront cost, simpler code, and faster time-to-market
Maintenance	Frequent dependency, tooling, and framework updates	Long-term stability and predictable maintenance

This doesn't mean an SMB should never use React, Angular, Next.js, or another modern framework.

If the website is actually an application, the calculation changes.

The point is to match the engineering solution to the business problem.

1. The Hype Cycle vs. Business ROI

The JavaScript ecosystem moves incredibly fast.

New bundlers appear. State-management approaches change. Frameworks introduce new rendering models. Build tools evolve. Dependencies are replaced.

For a large enterprise, keeping up with these changes can make sense. A large engineering organization may have dedicated teams, established architecture strategies, and the budget to continuously invest in its technology stack.

For a small business, the economics can be very different.

A typical SMB doesn't want to pay a developer every month simply to keep a brochure website's dependency tree healthy.

They want the website to keep working.

If a business website contains mostly:

Company information
Services
Contact details
Blog content
Testimonials
Product information
A contact or quotation form

then constantly chasing the newest JavaScript architecture may provide very little business value.

The question shouldn't be:

"What is the most modern framework we can use?"

It should be:

"What is the simplest technology that reliably solves this business problem?"

That shift in perspective can save both development time and long-term maintenance costs.

2. Browser Standards Have Leveled Up

Part of the reason JavaScript frameworks became so popular was that browsers historically lacked many convenient primitives for building sophisticated interfaces.

Developers needed libraries to standardize component behavior, asynchronous communication, interactions, and UI patterns.

Modern browsers are much more capable.

Many tasks that previously required substantial libraries can now be handled with native web platform features.

Native Componentization

Web Components provide native mechanisms for reusable custom elements and encapsulated UI behavior.

They aren't a replacement for every component framework, but they demonstrate how much component-oriented functionality is now available directly in the platform.

Clean Asynchronous Actions

The fetch() API provides a straightforward native way to communicate with servers asynchronously.

For many simple forms, API calls, and progressive enhancements, you don't necessarily need a large client-side data layer.

Rich UIs Without Massive JavaScript Bundles

Modern CSS has also become dramatically more capable.

Grid, Flexbox, transitions, animations, container queries, and other platform features can handle a surprising amount of UI work without introducing a large JavaScript dependency chain.

And when JavaScript is necessary, a small amount of vanilla JavaScript—or a lightweight library—can often be enough.

The browser itself has become a much better development platform.

3. Applications vs. Websites

This is probably the most important distinction.

Consider something like Gmail, an analytics dashboard, an ERP system, or a complex SaaS product.

These are applications.

They have:

Complex state
Frequent user interaction
Authentication
Rich client-side workflows
Large amounts of dynamic data
Sophisticated UI behavior

A serious application framework can provide enormous value here.

Now consider:

A local service provider
A law firm
A consulting business
A restaurant
A marketing agency
A company brochure website
A simple e-commerce storefront

These are primarily websites.

Their job is often to:

Explain what the business does.
Build trust.
Help visitors find information.
Generate a call, message, booking, or inquiry.
Rank well in search engines.
Load quickly on a wide range of devices.

Adding a large client-side application architecture to render mostly static business information can introduce engineering overhead without creating proportional business value.

The technology should serve the website—not become the product.

So, What Should SMBs Use Instead?

There isn't one universal answer.

The right stack depends on the business and the website's actual requirements.

But several approaches are often worth considering.

Lightweight CMS Platforms

A lightweight CMS can be a great fit when business owners need to update their own content.

For example, changing:

Service descriptions
Prices
Opening hours
Team information
Blog posts
Product details

shouldn't always require a developer.

Vanilla HTML, CSS, and Minimal JavaScript

For relatively simple websites, the traditional web platform remains extremely powerful.

A small HTML/CSS/JS application can be:

Fast
Secure
Easy to understand
Cheap to host
Easy to maintain

And there is something valuable about having fewer moving parts.

Lightweight UI Libraries

Sometimes a website genuinely needs interactivity.

That doesn't automatically mean it needs a full application framework.

For smaller interactive requirements, tools such as Alpine.js or Lit can provide useful reactive behavior without requiring an entire enterprise-style frontend architecture.

The goal isn't to avoid JavaScript.

The goal is to use the amount of JavaScript the problem actually requires.

It's Not About "Frameworks vs. No Frameworks"

This discussion can easily become tribal.

That's not the point.

A framework isn't inherently bad.

React, Angular, Vue, Next.js, and similar tools exist because they solve real problems.

The mistake is assuming that every website has those problems.

A useful rule is:

Choose architecture based on complexity, not popularity.

If you're building a SaaS dashboard with thousands of concurrent users and complex client-side state, use the tools that make that problem manageable.

If you're building a five-page website for a local business, ask whether you actually need the same architecture.

Sometimes the best engineering decision is not adding another abstraction.

Sometimes it's removing one.

Where I'm Taking This Idea: Solid-Vue

This line of thinking is also part of why I'm currently developing Solid-Vue.

Solid-Vue is an experimental, early-access project focused on making Vue-based business applications and websites simpler to build without turning every project into a large framework-heavy architecture.

The idea is not to replace Vue or compete with every existing meta-framework.

Instead, I'm exploring a smaller, more opinionated approach around the things a typical business project actually needs: Vue, Vite, file-based routing, Pinia, and a lightweight server layer.

It's still early access and experimental, so the architecture is evolving and the project is definitely not production-ready for every use case yet.

You can follow the project here:

Website: https://solid-vue.tech/
GitHub: https://github.com/solid-vue/solid-vue

I'd love to hear what other developers think about this approach—especially where you draw the line between a "website" and an "application", and how much JavaScript architecture you consider reasonable for a small business project.

References

Solid-Vue JS | The Minimalist Vue + Vite Web Frameworks (No relation to SolidJS or SolidStart at all)

Joni Ilman Pahmi — Sat, 05 Sep 2026 00:12:00 +0000

Solid-Vue JS is a lightweight Vue + Vite framework for small and growing businesses. File-based routing, a built-in server layer powered by h3, and zero extra config to wire together.

Features

File-based routing — every file in src/pages becomes a route automatically, via unplugin-vue-router.
A server, built in — src/server/api holds your API endpoints, served through h3 alongside your frontend. One dev server, one deploy.
Vite underneath — instant startup and near-instant HMR.
State management ready — Pinia is wired in out of the box.
Extensible via add-ons — install Tailwind CSS, icon sets, form validation, i18n, and more with the companion solid-vue-cli.

Quick start

Don't install this package directly — scaffold a new project instead:

npm create solid-vue@latest my-app
cd my-app
npm install
npm run dev

Usage

vite.config.ts

import { defineConfig } from 'vite'
import { solidVue } from 'solid-vue'

export default defineConfig({
  plugins: [
    solidVue({ mode: 'spa' })
  ]
})

src/main.ts

import { createSolidApp } from 'solid-vue/client'
import App from './App.vue'

const { app, router } = createSolidApp(App)

router.isReady().then(() => {
  app.mount('#app')
})

src/server/api/hello.ts

import { defineEventHandler } from 'solid-vue/server'

export default defineEventHandler(() => {
  return { message: 'Hello from Solid-Vue!' }
})

Plugin options

solidVue({
  mode: 'spa',        // 'spa' | 'ssr' | 'ssg' — default: 'spa'
  apiPrefix: '/api',  // prefix for file-based API routes — default: '/api'
  optimizeCWV: true,  // inject Core Web Vitals meta/preconnect tags — default: true
})

Package exports

Entry	Use
`solid-vue`	The Vite plugin (`solidVue`), used in `vite.config.ts`
`solid-vue/client`	`createSolidApp()` — bootstraps Vue, Vue Router, and Pinia
`solid-vue/server`	Re-exported h3 utilities (`defineEventHandler`, `readBody`, `useSession`, etc.) for your API routes

Add-ons

Add optional integrations to an existing project with the CLI:

npx solid-vue add tailwind
npx solid-vue add pinia
npx solid-vue add vitest
npx solid-vue add auth
npx solid-vue add i18n
npx solid-vue add lint
npx solid-vue add tabler
npx solid-vue add lucide
npx solid-vue add ofetch
npx solid-vue add unhead
npx solid-vue add vee-validate
npx solid-vue add vueuse

Requirements

Node.js 22+
Vue ^3.4, Vue Router ^4, Pinia ^2, Vite ^8, @vitejs/plugin-vue ^6 (installed as peer dependencies)

License

MIT

Join Early Access Programme

Solid-Vue JS is currently in its early access phase. We're early, and there's plenty still to build — but we'd love for you to try it and tell us what's missing. We'd be absolutely chuffed if you could test it out and share your thoughts.

You can give your review, feedback and contributing on our project by following link:
Our Page: https://solid-vue.tech/
Doc Page: https://docs.solid-vue.tech/guide/getting-started
Blog Page: https://docs.solid-vue.tech/blog/
NPMJS: https://www.npmjs.com/~joniilmanfahmi00-collab
GitHub: https://github.com/solid-vue/solid-vue

DEV Community: Joni Ilman Pahmi

I Turned My WordPress Store Into an MCP Server. Now an AI Agent Runs My Business — With My Permission.

The story that started it all

What is MuseSpark MCP Bridge?

Why MCP instead of another custom API?

The part I'm proudest of: the AI asks for permission

1. read_only

2. draft_only

3. require_confirmation

OAuth 2.1, built into WordPress

BYOK: Bring your own agent

Meet Blub 💙

What works today, and what doesn't?

What's been verified

What's still missing

What's next?

Your business, your rules

Alisha Catat: a local Gemma order assistant for my friend small print shop in Ciamis, Indonesia

What I Built

Demo

Code

How I Built It

1. A local model running on modest hardware

2. Gemma extracts data; ordinary code handles the money

3. A confirmation step instead of blind automation

4. From an order to a useful business record

What I Measured

Already Used in the Shop

Why Open Innovation Matters

1. No per-request cloud inference fees

2. Order data can stay on the shop's computer

3. It can run without a dedicated GPU

4. I can change the model and its behaviour

Honest Limitations

What I Learned

Prize Categories

Final Thoughts

Industry Notes for 2026: Why I’m Choosing to Build for SMEs Instead of Chasing a Corporate Engineering Career

1. AI Is Changing More Than the Way We Write Code

2. More Code Does Not Automatically Mean More Productivity

3. The Modern Engineer Is Expected to Do More Than Engineering

4. What Happens When the Junior-Level Learning Path Disappears?

5. Two Different Directions: Product Engineering and Systems Engineering

6. Theo Is Not Simply Saying That Nobody Should Become a Programmer

7. My Perspective: I Would Rather Help SMEs Solve Real Problems

Working with SMEs offers a different kind of relationship

The difference is not that SMEs are always easier

Corporate hierarchy is a different constraint

8. AI Should Help Us Deliver Better Solutions, Not Just More Work

9. This Is a Career Preference, Not a Declaration That Corporate Engineering Is Dead

Final Thoughts

Why Convention over Configuration Still Matters in 2026?

The Problem with Too Much Configuration

1. Faster Development

2. Less Boilerplate and Less Ceremony

3. A Predictable Project Structure

4. Convention Does Not Mean No Configuration

5. Conventions Make Frameworks Easier to Learn

6. Less Configuration Can Mean Less Configuration Churn

Convention vs Configuration

Why This Matters for Small and Growing Applications

The Real Value of Convention over Configuration

Solid-Vue Adds Per-Page Layouts and Its First UI Kit Add-on: Octans UI

Per-Page Layouts

Why definePage()?

Layouts Are About More Than Visuals

Our First UI Kit Add-on: Octans UI

What Does the Add-on Do?

We Don't Want the CLI to Guess

Using Layouts and Octans UI Together

Getting Started

What's Next?

Try It

Why I Built Solid-Vue JS: File-Based API Routing for Vue + Vite

The itch

What Solid-Vue JS is

Getting started

File-based API routes

Add-ons from the CLI

Deploying

1. `read_only`

2. `draft_only`

3. `require_confirmation`

Why `definePage()`?