Jev had the kind of weekend a small technology company hopes for. Access opened on Sunday, September 20. People started experimenting. When I wrote about it on September 22, the appeal was straightforward: fast, inexpensive AI scoring could make new things practical.
TypeSafe had introduced Jev on September 15, after what it described as two years in stealth. That is a long time to work before the public gets to see what you have made.
On September 29, OpenAI, the company behind ChatGPT, announced its Decisions API in limited preview. It addressed similar jobs: classify something, route a request, choose among supplied answers. General availability followed on October 22.
That is the part that scares me. You spend years getting something to work. You release it, have a big weekend, and almost immediately the customer has more places to get something like it.
The alternatives are already being built
OpenAI is one kind of competitor. Open source is another. By Monday, September 21, Simon Willison was already documenting open-weight recreations of Jev, including Kev. That was six days after TypeSafe's launch announcement.
Jared Palmer's Kev describes a family of Jev-like decision models you can train and run yourself. Its API follows TypeSafe's interface, and the project credits the coding agent Devin. NanoJev calls itself a small replica of Jev and publishes a model and training pipeline. Its README already records a September 20 update, five days after TypeSafe's launch announcement.
These projects offer routes to similar tasks. A familiar interface or a repository's benchmark does not establish Jev's speed, cost or quality across real workloads. Nor does OpenAI's announcement show that it copied TypeSafe's work. But a customer choosing a tool now has more alternatives to investigate.
My fear is the next version of that sequence: you launch, and a week later ten people have used their AI tools to make alternatives, some free or open source. That number is a scenario, not a count of verified Jev replacements. The actual projects make it much harder to dismiss the possibility.
The competitor does not have to reproduce everything you built. It needs to do enough of the job your customer was going to pay you for.
Adobe is getting the same treatment
ArtCraft's app projects take that ambition well beyond a small AI company. In an October announcement, the creator said he had used Claude Opus 5.5 to help recreate seven Adobe apps as free, open-source Rust programs. The list included Photoshop, Illustrator, Premiere and Acrobat Pro.
One of those projects documents specific limits. PhotoCraft's README says it is early alpha and unsuitable as a Photoshop replacement for daily professional work. It lists gaps in tools, professional workflows and plug-in compatibility.
A professional still needs the file to open correctly, the plug-in to work and the export to survive the next handoff. The unsettling change is the scope of the attempt: a whole suite, its source online, and an invitation for everyone else to help close the gaps.
From a buyer's side, that can be wonderful. More choice, less subscription pressure, and software you can change yourself. From the builder's side, it raises a difficult question: how much time do you have to earn back the work before an acceptable alternative appears?
A real need does not guarantee a sale
This changes how I read the usual advice about finding customers before building. Someone can have a real problem, like your answer to it, and still have little reason to pay your price once another option arrives.
Rob Snyder's PULL framework is useful here. His conversation with Lenny Rachitsky this week puts the customer's project and available alternatives at the center of finding demand. Snyder's framework asks what someone needs to finish, why it cannot comfortably wait, what options they have, and where those options fall short.
Four questions before the next feature
The alternatives question deserves more attention now. It includes a larger vendor adding the feature, an open model, a free application and the customer asking their own coding agent to build a version. The list may change between the first customer conversation and release day.
Free source code still takes work to run. Hosting, checking results, maintenance and recovery can make a paid service worth buying. But those costs need to be compared on the customer's actual task. They cannot simply be invoked as proof that the original business is safe.
Support and integrations may give people a reason to stay. They are also work someone else can attempt. I would want to see which customers keep choosing the paid product after they have tried an alternative, and what specifically makes the difference.
That is a harder test than getting someone to say the demo looks useful.
The bill still comes due
If I were preparing a release, I would put a credible free or open alternative beside the product before celebrating the launch. Give both the same customer task. Include the setup, checking and repair time. Find out where the cheaper option fails badly enough that someone will pay to avoid the failure.
Then repeat that comparison as the alternatives improve. A paid trial can answer something about one customer's choice today. It cannot promise that the same choice will hold six months from now.
In Tuesday's piece about quality assurance, I argued that faster production can leave less time to check the work. This adds another demand on that time: the thing you are checking may have a new competitor before you finish checking it.
I can be excited that more people can build useful software and frightened by what that does to the person who spent years building it first. Both reactions fit these examples.
The time a builder puts in does not come back when the alternatives arrive. The customer may still need exactly what you made. The question is whether enough of them will keep paying you for it.