Fluxion Interactive

What we build, and why

Serious software settles at the top of a market. We build for everyone below that line.

Serious software has a habit of settling at the top of a market. It gets priced for the largest budgets, sold in pieces, and taught mainly to people already working at that level. Everyone below that line improvises with spreadsheets and workarounds, not because they are less capable but because nothing was built for them.

We build for the people on the wrong side of that line. It means taking the expensive version of a tool seriously enough to understand why it costs what it does, then building something that does the real work at a price the rest of the field can reach.

Most of that work happens before anyone opens an editor. How does this job actually get done? Where do the numbers really come from? Which steps do people quietly dread, and why has nobody fixed them? Understanding that is the hard part. Writing the code is what happens once you have.

How we approach a problem

We like problems that look settled. When an industry has done something the same way for thirty years, there is usually a good reason for the method and a bad reason for the tooling, and telling those two apart is where the useful work is. The answer is rarely to modernize the surface. It is to keep the method, which people rely on for good reason, and rebuild everything underneath it.

That takes more patience than picking a framework. It means sitting with the people who do the work, learning a vocabulary that took an industry decades to settle on, and being willing to throw away a feature that demos well but does not survive a real week of use. We hold the scope tight so the parts that matter get built properly rather than shipping a shallow version of everything.

We are equally careful about what we claim. If something works within limits, we would rather name the limit than round it up into a promise. It is a slower way to write about software and it holds up better.

What we are working on

We name a product when it is close enough to release that naming it means something, which keeps this list shorter than it would otherwise be. Right now it isFilmBase for film and television production, Neon Charades, andOlive Meeting Notes.

How we make decisions

Solve the real problem
The interesting part of a brief is rarely the part that gets written down. We work out how the job is actually done before deciding what to build, because software that misreads the work is worse than no software at all.
Price it so people can use it
Software only the largest budgets can afford leaves most of a field exactly where it found them. We build for the people who have been priced out, and treat affordability as a design constraint rather than a discount applied at the end.
Learn the craft first
Every field has a working method that took decades to settle, and a vocabulary to go with it. We learn that before we design anything, because a tool that quietly asks people to abandon their method will lose to the spreadsheet they already trust.
Build what we can stand behind
The people who write the code answer the support email. It keeps us honest about quality, and it means whoever replies to you understands the system you are asking about.

Working on something hard?

Whether it is a question about our products or a problem you think we would find interesting, we read everything that comes in.