Technology
A pleasure for the people who use it. The best value for the people who pay for it.
Two groups judge the technology, and each group judges it on different things. The people who do the work want software that is a pleasure to use and helps them finish the job quickly and well. The people who pay for it want to know what their money buys. They also want to know if they are tied to one supplier for the next decade. You do not have to trade one against the other.
Software your people are glad to use
Nobody wants to admire the software. They want the software to stay out of the way and let them finish. Pages arrive ready for work, and every screen behaves the same way as the last one. The browser does not have to download and assemble an application first. Your people meet that difference every hour of every day. That difference separates software they use from software they only tolerate.
More for much less
Fusion needs a web server and one database. That list is complete. The platforms you compare it with expect a series of paid services beside them. Those platforms also charge you for each person who logs in. With Fusion, you pay for the machines you run, not for permission to run them. You have an application that fits your business, not one that makes the business change to fit it.
Fusion runs where you want it to
Fusion runs on any hosting provider, and you can move to a different provider in a day. If your policy, your board or your regulator requires it, Fusion also runs on your own servers in your own building. Nothing inside Fusion ties it to one supplier. No supplier can increase the price and expect you to stay.
When your IT team asks what Fusion is built on
The Rails stack
Ruby on Rails with Hotwire renders the screens on the server. The screens feel like a single-page app, without the front-end build machinery. Rails has twenty years of conventions, an active security team, and a talent pool the size of the industry. Any Rails developer can read the code on their first day.
The Elixir stack
Phoenix and the Ash framework run on the BEAM, the runtime built for systems that stay up. Declarative resources describe the domain once. Ash derives authentication, authorisation, APIs and audit trails from those resources, so nobody hand-codes them for each feature. LiveView keeps interactive screens on the server.
These foundations are mature, open source, and widely used. There is no proprietary runtime and no translation layer between the AI and the code. You hold the source.
Significantly less code
The safest code is the code nobody has to write.
A business application is mostly the same screens repeated: a list, a record, a form, a permission check. Teams write those screens by hand, and now they let an AI generate them. The result is thousands of near-identical lines, and nobody reads them closely enough to find the one line that is wrong. Fusion does not produce those lines at all. Fusion reads what our business objects already declare, and derives the rest from that.
What AI writes
class Person < ApplicationRecord
has_auto_controller key_attributes: [ :first_name, :last_name, :email ],
searchable: true,
field_groups: {
personal: [ :title, :first_name, :last_name ],
contact: [ :email, :telephone, :address_id ]
}
policy visible_to: [ :owner, :manager ],
editable_by: [ :owner, :manager ]
endWhat you get, with no further code
- A searchable, sortable, paged list of people
- A record page with the fields grouped as declared
- Create and edit forms, with each input matched to the type of the field
- A picker for the linked address, with inline create
- Web addresses and navigation, registered automatically
- Owner and manager permissions, enforced on every action and every query
For the same application, AI writes about 90% less code on Fusion than it does from scratch. The result is a massive increase in reviewability, maintainability and security.
One declaration, not a folder of files
The business object declares what it is and who can see it. The list, the record page, the forms, the web addresses and the permission checks all follow from that declaration. The repository has no screen file and no form template. A person or a machine cannot make a small mistake in a file that does not exist.
The screens read the business rules
Fusion inspects the type of each field and decides how to present it. A date appears as a date picker. A fixed set of options appears as a dropdown. A link to another record appears as a searchable picker with a create button beside it. When you change a business rule in one place, every screen follows it. Every screen stays correct.
A much smaller surface for AI to touch
When AI works on a Fusion application, it works on the business rules. The business rules are where your domain lives, and a person can read and review them in one sitting. The AI does not produce a thousand lines of near-identical plumbing that nobody will check properly.
Integration
Four reasons people buy an integration tier. All four are already here.
People buy an integration tier for four things:
- run this on a schedule
- retry it when the other end is down
- do not run it twice
- show me what happened
In Fusion, those four things are properties of the application, not a product you license and run beside it. In both the Rails stack and the Elixir stack, the work queue lives in the database that the application already has. So there is no broker, no second service and nothing new to keep in operation.
Run it on a schedule
You declare the schedule next to the thing it acts on. You do not declare it in a separate tool that holds its own copy of your business rules.
Retry when the other end is down
Failed work retries by itself, with a longer wait after each attempt. You declare what happens after the last attempt in the same place. Nobody has to watch a queue.
Do not run it twice
You can declare work as unique. Fusion keys each message that arrives from outside, so the system cannot process the same message twice.
Show me what happened
Fusion gives you an operator dashboard for the work itself, and metrics for the graphs your team already keeps. Fusion also shows the outcome on the record it belongs to, which is the part people want most.
The reference application has eight queues, five schedules, and four live third-party integrations. Those integrations are inbound webhooks, transactional email, media processing and a reconciliation sweep. The stack has no broker, no message bus and no integration product.
Not fashionable technology. Proven, stable technology and high-quality engineering.
We chose the stacks for their proven history, not for their news cycle. Our engineering still works well in year three. Bring your hardest workflow and see it reach production.