Jordan Nemrow and the trouble with a good idea

Jordan Nemrow’s music startup finally found an audience when he explained why it had failed. The account of its demise attracted about 100,000 blog visits in a weekend, he recalled, sending roughly 10,000 people to an app that had previously received about 100 views. For a founder hoping to sell music, this was an awkward discovery: the postmortem had a market. The product, by then, was beyond saving.

The company was Zillionears, a flash-sale platform for musicians. Its afterlife helped introduce Nemrow to other founders and, eventually, another job. Years later, he would co-found Woflow, working on the data and repetitive tasks behind commerce. Between those businesses lies a fairly useful education in how an appealing idea survives contact with people who might actually use it.

A very expensive compliment

Zillionears had a proposition its builders liked: musicians could sell directly to fans through short sales with dynamic pricing. The team spoke to artists, heard encouraging reactions, and treated those reactions as validation. Then they spent a year building and rebuilding. In his own telling, the conversations with artists largely stopped while the software work continued. The computer was providing answers to questions the customer had barely been asked.

The beta supplied a correction. Amazon, the payment processor, suspended the account over money-transfer compliance issues. Fans participated, but the company could not collect their billing. Nemrow and his colleagues paid the musician themselves and gave listeners the music. The system had successfully produced a transaction in which almost everybody got something except the business.

There was also a demand problem. Some fans wanted to support an artist; saving a few dollars was hardly the point. Nemrow’s diagnosis was unusually direct: the team had built for a market it did not understand well enough. The polished mechanism had received more attention than the reason anyone would use it.

“Our first beta test was a disaster”

Jordan Nemrow, on Zillionears

The obituary got the audience

The public account brought Nemrow into contact with Trey Griffith, who had also written about a struggling startup. They met over drinks and kept in touch. Nemrow went to work at Shop It To Me because he wanted to understand a startup whose business was functioning. That is a more modest ambition than inventing the next great company, and a rather practical one.

By 2014, Griffith had recruited him to Teleborder as a software engineer. Teleborder made software for organizing employee visas. Nemrow joked about the business’s lack of glamour. After trying to change music sales, he was working on paperwork. Paperwork, of course, has the considerable commercial advantage of existing whether anybody finds it glamorous or not.

Here was an actual consequence of talking honestly about failure: a relationship that led to work. The failed company stayed failed. Its founder acquired colleagues, experience and another way to learn.

Beer, snacks and repetitive work

Nemrow kept making things. At the 2015 LAUNCH Hackathon, he and Dan Polaske collaborated on Booz Club, an application for finding a particular drink at nearby retailers. A user supplied the drink and a phone number. The application called shops through Twilio, then sent back the results by text. It compressed a series of tedious calls into a request and a reply.

At the following year’s hackathon, the pair worked on SnackBot. Employees could ask for office snacks through Slack, choose among suggestions, and leave the office manager with a shopping list to approve. Nemrow handled the backend and brought the designs into Ember. The project’s own account of how it was built consisted of a coffee hashtag. Hackathon documentation sometimes knows exactly when to stop.

The projects were small, but their chores were specific. Someone wanted to locate a bottle. Someone else wanted to avoid collecting snack preferences one conversation at a time. In each case, software took responsibility for the intervening steps. That recurring interest in removing repetitive work would become central to Woflow.

Nemrow described Woflow’s beginning with an offer on Facebook: “If you copy and paste at work, I want to buy you a beer.” The resulting exchange helped bring him together with Will Bewley, an early user who became his co-founder. The first tool automated browser actions. The partnership grew around something that somebody could already try.

A menu is a small database with opinions

Nemrow and Bewley founded Woflow in 2017. They worked on it as a side project at Workshop Cafe in San Francisco. Customer feedback drew them toward food-delivery companies and the task of turning merchant catalogs into usable data. A restaurant menu may look finished to a diner while still requiring considerable work before another system can use it.

The founders also changed what they sold. Early on, Woflow licensed software by the seat, charging $150 to $250 per month. Later it offered an API for data services with transaction and subscription pricing. Customers could buy the result of the work through software rather than organize every step themselves. Pricing remained difficult because prospective customers often could not calculate their existing total cost.

By 2021, the founders’ advice was to specialize before broadening the market. It reads differently beside Zillionears. There, an agreeable reaction had encouraged a long building exercise. Here, repeated customer work helped narrow the product. The lesson had become visible in the shape of the company.

Construct Capital co-led Woflow’s Series A with Base10 Partners. The investment announced in January 2022 was $7.3 million. In its later account of the investment, Construct described a business that had already digitized more than 60 million items across several regions, including North America, Europe, Asia, Latin America and Australia.

The investor’s explanation emphasized the basics: merchant information had to be made usable before the more visible digital experience could work. Woflow combined machine learning with tools that automated and assisted human workflows. For Nemrow, the commercial opportunity lay in making those operations repeatable. A customer might only see a catalog. Behind it sat a process that had to keep delivering.

Let the engineers get on with it

Growth brought another version of the repetitive-work problem inside Woflow. Its engineering team began with Heroku, then moved production servers to Amazon’s Elastic Container Service. The second arrangement gave the team more control, but concentrated infrastructure knowledge in one colleague, senior engineer Andrew Harsata.

Other engineers needed help with changes as small as updating an environment variable. The team considered building internal tools to make the setup easier, then adopted Porter. Engineers could again deploy and troubleshoot through a simpler interface while the underlying infrastructure remained in their own AWS account. The story is instructive precisely because the obstacle was so ordinary. A platform built to remove operational friction had accumulated some of its own.

Nemrow later described applying a similar separation to AI prompts. Woflow kept them outside the main code repository and managed them through Vellum. If an output needed improvement, the team could inspect the execution, adjust the relevant prompt and deploy that change independently of the application servers.

More involved changes could still be tried in a development environment. The aim was a shorter route from noticing a problem to correcting it. It is the same practical question at another level: who needs to do what before the next piece of work can move?

The work of letting go

In April 2025, Nemrow’s account of Woflow included a harder personal adjustment: delegation. He had begun as its sole developer. By then he was discussing the business as CTO, having previously held the CEO role. The work had grown beyond the person who wrote the original tool.

He also spoke about the lengthy process of making a distributed team work well together. Woflow introduced quarterly in-person Shipathons and annual offsites. The engineer’s job now included building the conditions in which other engineers could make progress. That requires a different sort of patience from fixing a line of code yourself.

In a later account of a Woflow gathering in Bend, Oregon, Nemrow described shared meals, golf carts, horseback riding and glow-in-the-dark pickleball. He connected time together with clearer conversations and faster collaboration afterward. There is something pleasingly physical about this chapter of a software career. The team that works through screens occasionally needs to spend time in the same place, preferably with a sufficiently ridiculous game.

Still asking questions in public

Nemrow and Bewley also brought their conversations into public view through Vibe Flow. When they introduced a relaunch in 2025, their first guest was Carted founder and CEO Holly Cardew. They discussed agentic commerce, messy product data and the human element in trust. By the final episode of that year, the pair were exchanging predictions for 2026 and software presents they had built for each other.

Woflow’s current offering extends to custom AI agents, tools and data foundations for businesses. The broader ambition still rests on a familiar difficulty: useful systems have to fit the information and work already inside an organization. Nemrow’s own professional introduction makes the point plainly: an enterprise cannot simply become AI-first by flipping a switch.

His career supplies several reasons to take that seriously. A musician can like an idea without needing the product. A capable engineer can become the person everyone else must wait for. A distributed team can have all the software it needs and still benefit from a shared meal. Nemrow keeps returning to what happens between the proposal and the result. There is usually more work there than the proposal admits.