From 0 to 1 and back again: a startup story

I recently wrapped up a two-year venture, launching a startup alongside two trusted colleagues. This was my first experience starting a company, after having spent 8 years at organizations from large public orgs to mid-stage private tech companies.

Spoiler: we were not successful in creating something that enough people found valuable to justify continued effort, and after two years, we decided to close shop. Despite that, we built some cool, if niche, products, and I personally learned a ton. Coming away from the experience, I can say that it was certainly the highest-density period of learning in my life, and well worth the time spent.

AssetClass

July 2021 - Feb 2022

It was late 2021, VC money was flowing like never before. Markets were at their all-time high and bored apes were selling for six figures. The Gamestop bubble was only several months in the rearview mirror. It was the era of the retail investor.

In September of that year I joined a team of two close colleagues from Sonder to build an app to fill what seemed an obvious need at the time: help investors track their assets.

Our hypothesis:

Young, self-directed investors with a fragmented set of investment accounts lacked a modern way account for and manage diverse investments holistically.

Enter AssetClass: an easy-to-use app that tracks all of your investment accounts in one place and makes smart recommendations to help you get the most out of your savings.

We launched AssetClass in late November 2021 and eventually grew the product to over 1500 users–initially good traction! After 4-5 months investment, however, we decided to pivot.

AssetClass’s tech stack

We used a really straightfoward, server-driven stack to build AssetClass:

Internal:

1. Rails for server rendering, database management, background jobs
2. Postgres
3. Stimulus for interactivity
4. Tailwind for styling
5. Turbo-native for mobile

External:

1. Finicity for most financial account connections
2. Plaid for certain connections, like Robinhood
3. Alchemy for blockchain integrations
4. Coinbase for crypto prices
5. Polygon for security prices

Headwinds

In our view, there were several reasons why we didn’t see a sustainable path forward for AssetClass:

Market downturn

In November 2021, the market started to turn. Low interest rates and federal stimulus had pushed huge sums of money into the stock market, creating an environment of hugely inflated valuations. Starting in February of that year, had inflation started to tick up , and the Fed began to make noises about hiking historically low interest rates, sending stocks into a tailspin.

There was some basic human psychology at play. When you look at your portfolio and everything is up, it’s amazing. You get this incredible hit of dopamine that comes with the knowledge that you’re a bit richer than the day before. But when things are treding in the other direction, well, it’s not as fun.

Our users weren’t professional investors–they weren’t getting paid to watch the market. So what did they do when the dopamine dried up? They stopped looking. Our engagement plummeted alongside the S&P 500.

Technical infeasibility

Poor data quality

We used Plaid and Finicity to create and maintain connections to our users’ FIs, and the quality of the data was very poor. It’s hard to fault Plaid and Finicity too much, their jobs are hard. These companies are essentially storing your login information and then periodically scraping the data right out of the dang HTML! It’s challenging to impossible to get clean data over a long period of time.

Some of the issues we encountered were quite fun:

In employer-sponsored E-trade accounts, Finicity would report that a user held a certain number of shares, but would not be able to tell us what those shares were. “Sarah has 10,000,” they would say. How much is “10,000” worth? We had to try to back into the answer based on other clues in the API response.

Other times, scrapers would fail to pick up a decimal point or parse a comma, and the data we would get back could be off by a factor of 10 or 100 in either direction. You might log on to AssetClass one day after we had pulled fresh data for your Schwab account and find that you were either an overnight millionaire or had simply gone broke in the same period, prompting panic.

Data issues, although not within our control, fomented distrust amongst our users.

Luddite FIs:

Certain FIs (Vanguard and Schwab being the biggest offenders) would just block scrapers during peak hours. From around 9 to 5 Eastern, any new connections would be rejected. We built workarounds to remind users to come back and connect those accounts later, but that was a terrible experience and most people who encountered this issue never came back.

As it turns out, it’s very hard to explain the business and technological context that leads Vanguard to block Finicity during the day, and for us in turn to be unable to connect your account. To a user who doesn’t know any better, it just seems like our app is garbage.

Lack of willingness to pay

This is the big one–people just weren’t going to pay for this product! Even though some continued to get value out of it despite the market downturn, all user interviews and monetization experiments pointed toward the fact that so few people would be willing to pay for it that we could never get ahead even if we were to significantly drive down customer acquisition cost, mostly due to the marginal cost structure of working with Finicity and Plaid.

Factor.fyi

Feb 2022 - May 2022

Factor was our first and shortest-lived pivot after the gradual decline of AssetClass made us question the underlying business fundamentals. Crypto was still rolling strong, and we were astonished by the rise of Dune , which allowed folks to create dashboards with mountains of on-chain data using SQL as the interface.

With no other validation other than the vague intuition that such a product should exist for traditional financial data, we set off to build essentially a clone of Dune with financial data like stock prices, data from the FRED, Forex rates, etc.

Factor’s tech stack

Internal:

1. Rails for internal API, data modeling, background jobs, etc.
2. Two Postgres instances, one for application data, and a warehouse for financial data
3. React for client-rendering
4. Tailwind for styling

External:

1. Coinbase for crypto prices
2. Polygon for security prices
3. FRED for public economic data

Headwinds

No real problem to be solved

Although I personally loved this product, there just weren’t that many people out there who can both write SQL and care a lot about getting nitty-gritty analyses that they wouldn’t be able to get someplace else for less effort. Even though we got , and continue to get, many signups, we had very few active users and essentially zero query authors on the platform.

We didn’t understand our customers

We assumed that Dune’s users had been regular folks, but we missed one key insight: Dune’s paying users were blockchain developers who were using Dune as a monitoring tool for their own projects, not outside investors using it as a research tool, as we had assumed. That assumption had led us to believe that there were far more regular folks out there with the ability to write SQL than there actually are. The choice of interface, although interesting and flexible, didn’t resonate with our target market of “protail” investors, researchers, and fintwit content creators.

We later added some targeted features for financial content creators, like the ability to embed interactive charts in places like Medium and Substack, but the fundamental problem still existed: we weren’t solving a real problem for anyone.

Yuzu

May 2022 - Dec 2022

When we realized that Factor was looking a bit more like a passion project than a real business, we took a beat before moving on. We focused on problems that we had encountered building AssetClass and Factor.

A prevailing theme was data. With AssetClass, we had issues with unreliable customer financial data. We decided that it wasn’t a good idea to try to outdo Plaid or Finicity (we didn’t think we could do any better). Instead, we chose to focus on the other side of the data: public markets data, the prices of stocks, bonds, options, etc. We understood from building two fintech apps that building with this data comes with a number of unique challenges, including:

1. Inefficient APIs: All financial data APIs out there are built on the REST paradigm, which exposes a fixed schema by which you receive data. If you’re building an app or website, you might need to call multiple API endpoints to grab all the data you need to render a screen, creating a noticeable drag on performance. Most companies will choose to “scrape” all of this data into their own database in order to create an internal API more tailored to their own internal use cases.
2. Cache invalidation: because most companies choose to do the above, they run into issues with stale data. Financial data, especially in equity markets, are incredibly dynamic. There are multiple events that can force you to rewrite entire tables unless modeled correctly: 1. Dynamic symbology: Stock tickers change on a daily basis. COIN might mean Converted Organics, Inc. one day and Coinbase Global, Inc. the next (yes this is real). 1. Stock splits: When a stock splits, all the prices previous to the split must be “split-adjusted.” For example, if APPL is trading at $100 one day, and the following day splits 5-1, it will start trading the following day at $20. To avoid the price appearing to jump from $100 to $20, you must adjust the previous days’ prices to reflect the 5-1 split.
3. Bandwidth constraints: Most providers will put a cap on the number of streaming connections you’re allowed to create, generally somewhere in the single digits. If you want to stream live prices to your clients, you have to proxy that stream and rebroadcast it out to your clients, which can be a big lift for a startup.

We solved these problems with two key product innovations:

1. GraphQL and SQL APIs: GraphQL and SQL are both incredible ways to grab data in a flexible manner. They are really two sides of the same philosophy, with GraphQL generally being a frontend tool, and SQL a backend tool. Offering both APIs offered customers the ability to flexibly grab data to quickly build MVPs of products without needing to build their own cache of financial data.
2. Unlimited websockets: Leveraging newer technologies like Elixir allowed us to build scalable services that could serve a huge number of downstream clients.

Successes

We grew Yuzu to several paying customers, from startups to small tech-enabled hedge funds.

Technically, the infrastructure was huge accomplishment for a dev team of two. We built a high-scale GraphQL API, a high-performance data ingestion pipeline that was processing gigabytes of data every second, and even built our own Postgres frontend (replacing pgbouncer) to scale the number of clients that could connect directly to our data warehouse.

Yuzu’s tech stack

1. Rails to manage our application database (customers, usage, metrics, etc), and schedule background jobs to perform bulk ingestion of OHLCV data for stocks and crypto on a regular cadence (generally every 30 minutes).
2. Postgres for our application database.
3. TimescaleDB for our time-series data warehouse
4. Golang for two services: 1. One which ingested real-time crypto data from Coinbase, Binance US., and Binance International, rolled that data up into 1-second bars, and sent it to the Rails app via WebSocket for warehousing. 1. A replacement for pgbouncer which was able to better handle per-user authorization.
5. Node + Typescript for the GraphQL API.
6. Elixir + Phoenix for two services: 1. One which ingested delayed the SIP feed, every trade and quote from all U.S. exchanges, rolled that data up into 1-second bars, and sent it to the Rails app via WebSocket for warehousing. 1. One to handle inbound websocket connections from clients.

After getting rejected from YC on this idea, we took stock of our progress. Several months work with several customers, but diminishing prospects. At this time venture fundraising was at it’s lowest point, and fintech was taking it especially hard. Many of our customers and top prospects were not getting funded, and we ourselves were getting negative signals from the market.

Lesson: Market size

YC’s overall reason for rejection was that there just wasn’t enough money being spent on financial data to justify a venture-scale business in the space, which could explain the perceived lack of innovation. Had we done more research and not been as myopic about the problem space, we could have invalidated this idea from the jump.

Trava

Jan 2023 - Sept 2023

After winding down Yuzu at the end of 2022, we really went back to the drawing board. With every industry on the table, we evaluated a number of problem spaces for areas of high opportunity: a space with good match for our skill sets, a large market, and a clear “why now” would be present.

After invalidating a number of ideas, we eventually decided to go back to the travel space, as we thought there was an opportunity to develop new products in travel powered by a new wave of AI models that seemed poised to upend many industries.

Trava’s first iteration was a hotel search and booking website that helped travelers filter through the noise of larger online travel platforms and just find great boutique hotels in popular destinations. We believed that there was an opening for a startup to tackle this niche between travel magazine and big online booking platform. We know of FHR and Mr. and Mrs. Smith , and thought we could bring a bit more panache to the category.

A few iterations later, we arrived at a different problem, travel planning. Trava’s second iteration was an AI travel planner that helped travelers plan great trips given complex itineraries or unfamiliar destinations by putting together a trip plan that catered to the needs of the individual traveler.

Both of these iterations monetized by taking a commission on the hotel room, at a rate between 3-4% based on the end booking platform. In an $800B market, capturing even a small percentage of these bookings translates to huge business. We assumed we could acquire customers cheaply by bidding on keywords that bigger travel players weren’t as keen on.

Trava’s tech stack

1. Rails
2. Postgres
3. Preact for interactivity
4. Tailwind for styling
5. ES Modules and import maps for js delivery

Headwinds

After the sub-pivot to AI travel planning, we did see a lot of encouraging signs of adoption. We were able to drive a lot of organic growth via AI newsletters, ProductHunt, and socials, but in the end we were able to convert very few travelers to book a hotel through our affiliate links. Even driving supposedly high-intent traffic via paid search yielded very little conversion.

Ultimately, with our money running low, we could not justify raising funds on the weak metrics we had. With very little available runway remaining, we made the hard, but necessary decision to wind down the company.

Lessons and growth

Ultimately, the time spent building these products was incredibly useful from a learning and career growth perspective. Even though I would have loved to have more success, the lessons learned were invaluable. Some specific learnings for the next at-bat:

1. Validate Swiftly: Our strength lies in rapid product deployment. However, we often found ourselves investing too much time coding before identifying potential flaws. It’s crucial to quickly determine the viability of an idea with proactive and thorough research.
2. Target Large Markets: If securing venture capital is your aim, remember that a limited market will be a deal-breaker. Investors are on the lookout for opportunities that offer 100x returns. Ensure your product appeals to a wide audience to achieve that potential.
3. Innovation Over Novelty: Instead of trying to create an entirely new category, it’s more effective to introduce innovations within existing ones. This approach generally resonates better with potential customers.
4. Understand the ‘Why Now?’: If you’re puzzled about why your brilliant idea hasn’t been executed before, the answer is not because it hasn’t been thought of. Chances are, it’s been tried and didn’t take off. If you don’t have a specific reason why it will work this time, it will very likely fail again.
5. Recognize Your Business Strength: The seven business powers is a framework we talked about all the time, it’s a useful framework for analyzing your model’s defensibility against incumbments.