Fluxon's big idea: fewer builders.

At Google, Erad Fridman noticed something awkward about the arithmetic of software. One engineer on an outside team kept fixing the bugs and shipping the difficult work. When assignments went elsewhere, quality slipped. There were plenty of people. The results depended disproportionately on one of them. Adding another chair to the meeting would not necessarily help.

That observation became part of the thinking behind Fluxon, the San Francisco software development company he co-founded. Its proposition is deceptively simple: assemble experienced people around a specific problem, put them close to the customer, and keep the distance between a decision and working software short. The thing being sold is judgment, delivered through code.

First came the team. Then came the business.

Fluxon's origin has an appealing lack of pitch-deck choreography. Fridman told the Nasdaq Entrepreneurial Center that the company began in 2017 with friends who wanted to build things together. They had no particular product in mind. People began bringing them ideas. Demand for the team's work supplied the business plan.

The founders include Fridman, CTO AJ Ross, COO Ena Zheng, and CPO Jen Huang, whom Fluxon's current writing identifies as a co-founder. Product, engineering, and operations all have a place in the story. That matters because a new application rarely fails only at the level of code. Someone has to decide which problem deserves an application at all.

By August 2022, Fluxon described a bootstrapped business with more than 150 people. Its current careers page advertises more than 300 builders and a fully remote model. Profit sharing, paid parental leave, and yearly meetups appear among its benefits. A distributed company still needs people to trust one another when the answer is inconvenient.

A month is enough to ask a better question

Consider Puzzle. Founder Sasha Orloff was weighing three business ideas. Accounting offered a promising frustration: tools oriented toward monthly reporting did little to give founders an immediate picture of financial health. Market research could sharpen the idea. A working application could reveal whether somebody would actually use it.

Fluxon's case study says a core engineering team was assembled within a week, an initial product was working in under a month, and a market-ready MVP followed within a quarter. The team worked across product definition, interface design, architecture, and engineering. The point of moving quickly was to put the proposition in front of prospective customers while decisions were still cheap to change.

Eppo needed a different kind of help. Its founder, Chetan Sharma, already understood experimentation systems. Fluxon joined as the first engineering team, translating product and data models into an application and its underlying architecture. Later work included feature flagging and a shared Rust core for SDKs in different languages. The relationship continued through Eppo's acquisition by Datadog in May 2025.

Zapier supplied the enterprise version of the problem: an established technical organization with a deadline. Fluxon helped build Tables and Interfaces for the company's 2022 conference, adding data fields, form connections, appearance controls, and keyboard navigation. Zapier product director Taylor Halliday said the team shipped code within its first week. Useful progress sometimes looks like a cursor moving correctly between cells.

"They embedded with our product teams, and shipped code within the first week."

Taylor Halliday · Director of Product, Zapier

The expensive part can hide inside the demo

Fluxon's services now span technology strategy, full product builds, AI products and agents, and platforms and core systems. Its work on Google's workplace mapping product shows how those categories overlap. The project brought data from more than ten systems into one map-based experience, with natural-language questions and links back to underlying information. A conversational answer becomes more useful when someone can inspect its basis.

There is a less flattering side to the AI boom, and Fluxon's own writing supplies a memorable example. A team demonstrated an architectural tool that enlarged a kitchen on command. Beyond the polished demonstration, its plans could contain unusably small rooms and staircases going nowhere. The instruction had been followed. The building had stopped making sense.

That failure changes the engineering question. A designer exploring rough layouts can tolerate mistakes that would be unacceptable in construction documents. Fluxon argues for evaluation sets drawn from actual requests and past failures, repeated whenever a model, prompt, or workflow changes. Domain experts define acceptable results. Software checks and human review enforce the boundary.

Braintrust is a fitting customer in this context. Fluxon helped build its early evaluation interface, including a prompt playground and visualizations for large datasets. Measuring AI behavior becomes a product problem of its own: people need to compare results, understand changes, and find the cases where a promising improvement quietly makes something worse.

Buy a shorter route to a decision

Commercially, Fluxon occupies the space between hiring a permanent team and commissioning an outside product studio. Clients purchase development services and embedded expertise. The alternatives include building internally, assembling independent specialists, or engaging another engineering consultancy. Fluxon's positioning rests on experienced teams that can make product decisions as well as implement them. That is a useful distinction to test in a proposal, rather than accept from a slogan.

A buyer should compare the total cost of reaching a usable release: team fees, internal management time, rework, and the delay before customer feedback arrives. A smaller roster only helps when its people can handle the problem. It also requires access to decision-makers. An embedded engineer cannot shorten a decision that spends three weeks waiting for approval.

The practical lesson travels beyond Fluxon. Name the outcome before choosing the team. Ask to see working software early. Preserve the failures as test cases. Keep the builder close enough to ask why. In September 2026, Huang wrote that the Google product playbook she brought to Stripe had initially failed because it supplied process before the company needed it. Experience becomes valuable when it tells you what to leave out.