Hacker News Reader

Comment by kingkongjaffa | Hacker News Reader

What customer discovery have you done so far?

> turn psuedo-software Excel files into real-software Python

I'm curious how many people actually have this problem. It strikes me that the corporate environments that are building big hairy excel files probably have locked down IT where running python is a difficult thing to do.

In the environments where you can get some kind of python running, it's probably likely that developers are looped in as part of an efficiency project, and doing some kind of voice of the customer / requirements capture and starting to build from scratch more or less.

There's a vanishing window for stuff like this, if you're a Microsoft shop like 99% of the corporate world I think you are turning those excel files into power apps and powerBI dashboards, before you are hiring python devs.

View on HN

> What customer discovery have you done so far?

Me and my two cofounders spend the past 4 years working on Mito (https://trymito.io) -- where our customers are primarily large finance shops (including some bulge bracket banks you've heard of) that has a really concrete goal of getting users out of Excel and into Python. It's not every finance shop, but a quite a few are trying to make this transition. This usually means: multi-day Python trainings, a Python support team, a few developers who semi-full-time job is helping transition existing Excel processes to Python.

We built Mito to be a tool for the Excel-first users - we tried to make it easier for them to use their existing spreadsheet skills to write Python. But in working with the developers that support these new Python users, it became clear to us that there's a big pain point around:

1. I'm a dev who was given a big, old Excel file

2. It has a lot of business logic in it, understood by the person who made it, but not by me - who is tasked with turning it into real software

3. I have to spend 100s of hours: trying to understand the file, faithfully replicating the logic, and testing for consistency - to convert this to an Excel process.

I personally have been this developer in quite a few cases - just as support for Mito and helping these Excel users trying to transition to Python. Some Excel files literally take 300+ hours to "rebuild from scratch" in Python. It's often very engaging work, but brutally slow - so we're trying to automate as much as we can with Pyoneer.

> There's a vanishing window for stuff like this, if you're a Microsoft shop like 99% of the corporate world I think you are turning those excel files into power apps and powerBI dashboards, before you are hiring python devs.

I think this is a really fair point! We're not sure exactly what a reasonable business model really looks like, long-term. Right now, we're really focused on finding the developers for-which this is a big pain point, and seeing what we need to prioritize to make their lives better. I'm one of those developers...

Hey, thanks for the reply!

My next question would be how did Mito go?

What MMR did you get to?

How strong was the PMF?, 4 years seems like a long time to test this product, and I'm not sure if the overall market for this is too small. Is it the trap of dogfooding (building the thing you wish you had) without sizing the market?

Mito site says: Trusted by dozens of fortune 500 companies, how penetrated is that really? Is it one dev in each company on the free tier or entire departments/teams using this on the $150/month/user plan?

I built something similar (excel / python space ) but it was really just one feature as part of a larger platform, not something I would build a company around.

Sure thing - thanks for the good thoughts!

We're still working on Mito - it's not a retired product by any means. Pyoneer is just another stab at the same problem for a different user group.

MMR-wise, we scaled to profitability. PMF-wise, we have not reached this. We have large customers who make up the bulk of our revenue who love the product, and use it quite effectively as the basis for their entire Python program, but, transparently, scaling is hard!

> Is it the trap of dogfooding (building the thing you wish you had) without sizing the market?

Very possibly. But I think this is a much bigger pain point at large orgs with legacy processes than you realize, though. Every large bank has an entire development teams that are tasked with transitioning legacy processes out of spreadsheets. We're aiming to improve the efficiency of these developers dramatically.

For some of the spreadsheets I've personally automated, I think this would take 300 hours of work and make it like 5...

From their website it sounds like they know there is a market for this because they’ve been doing it manually for a while:

“Our founding team spent the past decade transitioning Excel files to Python - from startups to insurance companies to bulge bracket banks.”

Yeah, we built this because we wished we had it! I've spent literally thousands of hours reimplementing Excel workbooks in Python as support for our previous shot at this problem - which was a spreadsheet that generates Python code as you edit it.

> if you're a Microsoft shop like 99% of the corporate world I think you are turning those excel files into power apps and powerBI dashboards, before you are hiring python devs.

This is a good incremental decision, but once everyone's done it, perhaps an edge can be found by doing it properly. As much as IT folk love administrating Microsoft products, the products are terrible for the users.

'I'm curious how many people actually have this problem. It strikes me that the corporate environments that are building big hairy excel files probably have locked down IT where running python is a difficult thing to do.'

FWIW I have worked at 3 financial companies (including my current job) where Excel is used heavily and where "desk quants" are allowed to use Python.

Additional thoughts:

How are you modeling the input data? Are you using dataclasses and type annotations? something like https://docs.pydantic.dev/latest/ ?

How/Where is the data stored? Not inside the notebook, right?

Currently:

1. Data remains stored in the excel file. The generated script pulls the raw data directly from the notebook - but it's a single read_xlsx call. So if you want to switch it out for an API call, db read, whatever - it's easy to do so.

2. We model data as primitive Python data types, or, if it's a table, as a pandas dataframe.

Currently, we detect at most one table per sheet, and it's gotta be contiguous. These are pretty huge limitations we'll be relaxing soon -- but we wanted to get something out as soon as it would have been useful to one person -- and in it's current state, this would have helped me with some of my larger Excel automation projects :)

Reply on news.ycombinator.com