Comment by dejv | Hacker News Reader

Comment by dejv | Hacker News Reader

I've build complex app for managing vineyards and wineries. It has tons of features: time tracking, input tracking, harvest and production features, mapping, tons of budget/cost analysis.

It turned out, it is hard to convince farmers to ditch their trusty excel sheets and notepads and start typing all those info into computer program. I managed to find few customers, but they haven't stick for longer than one year.

I spent about one year of fulltime work (spread over two years). I always tried to expand the product: I started with vineyard management software, then add the production part and then started coding all the CRM, POS and warehouse management. I hoped to attract more users with more complex solution, but I was wrong.

After three years I am still using it daily (I do own winery), but I am only active user right now and I did give up trying to sell it. I do some occasional development, from time to time when I need something in my farm, but thats it.

This is a common mistake: building a product based on assumptions, and not on the market's demand. I've learned not to add a feature before I have someone who paid an advance. Secondly: your product might be to overwhelming and doing to much; experience has thought me that complicated products are a though sell. Try to reduce it to it's most basic use-case, and sell that (a simple app that doesn't require any explanation at all). Once you have paying customers you'll be able to upsell by offering your more advanced features. People are reluctant to change, so you need to expose them gradually.

You are right. I am currently building another product, which is lite version of what I have and which is applicable to broader market: not just wine farmers, but all farms and consttuction companies.

>This is a common mistake: building a product based on assumptions, and not on the market's demand. I've learned not to add a feature before I have someone who paid an advance.

I first came across this sort of advice here:

The Montana Mogul: RightNow CEO Greg Gianforte (Part 1)

http://www.sramanamitra.com/2008/07/31/the-montana-mogul-rig...

Interesting story. RightNow was later sold to Oracle, IIRC, for a good amount.

Greg used a similar technique to what you advise.

The part of the interview series about Brightwork (Greg's first startup) and their telesales process and why McAfee acquired them, is also interesting.

Thanks for the tip!

How does it handle payments, payable/receivable etc (if applicable)? I have found that in these cases often times the software handles the operations well, but the business logic is still tied up in legacy POS and things like this which makes the software more of a nice to have than a "I'll just do it the old way". I'd also be curious about the UX (am a designer)

Product integrated with 4 major accounting systems, so it was more like frontend for those legacy stuff. Major thing was warehouse/logistics system which was my own.

In wine business thats quite complex thing: you might want to sell bulk wine, you might blend different stock together or bottle one lot in multiple times. There is strict requirements by govt about declaration of those thing. Each country qlso have different requirements and reporting formats.

I've build a wine tasting event app a couple month ago. Replacing the tasting sheet for tasting events with a simple web app to make it easier for the organizer to collect and analyze feedback and market after the tasting.

Got a few hundred users but no real traction yet :-/

Can you share a link? Would like to check it out.

https://www.viaromy.com/

Still 'beta' but you can signup under /signup/ Please share feedback :)

Did you figure out why customers would leave? I've been thinking about doing something in the "most people use a spreadsheet" space and hearing that people went back to it after a year of using a dedicated product is a little worrying.

I have a similar story - one of our products at $DAYJOB is a kind of CRM/ERP SaaS for a specific niche.

It pays its way, but at a huge cost of time spent on support and maintenance. When non-trivial feature requests come in, we can't feasibly drop everything else for long enough to implement it. We signal this by asking the customer to pay a lot (compared to our SaaS subscription price). Usually this dissuades them.

Every so often, we lose a customer -> support dies down -> we can add some real direction and features to the product -> we gain more customers -> we get swamped under support and maintenance. The cycle continues. I don't know what the solution is.

With spreadsheets, the customer can always fall back to cobbling together a new report or visualization by themselves.

It was hard to get all the company to use it. If you use it just for small subset than it is not that valuable.

Say you are tracking work done in vineyard, but nothing else. Then your calculation of price of produce is off, because you havent add the price of input. There are multiple roles in the company and they are usualy using they own systems for reporting.

Also quite a lot of production tracking have to be done on paper using special notepad with marked pages (another funny story) and people dont want to do this bookkeeping twice.

Is this a web app or a desktop app?

web app and unfinished mobile app (native iOS)

I do some beer homebrewing and (fairly or not) my first thought was of the BeerBug digital hydrometer, which was a temperature/density meter that wirelessly synced to an online service. The problem was that the website was the only way to read the data. And then the website went down for months :-/ . I didn't buy it but the whole debacle made me suspicious of depending on online services for brewing.

I'd suggest you might have more luck with a desktop app. Could wrap your existing web app with Electron or Sciter to avoid needing to rewrite the GUI. Businesses need to know they can rely on the software they use, and that's an easier sell when they can run it on their own hardware. I'd suggest a better business model is a relatively low cost for the software but charge for an optional support subscription.

Reply on news.ycombinator.com