Goldenseal Pro Cash Flow (July 23)

The cash flow for creating software is a lot like building a spec house. Income only happens when the project is finished, so the builder needs some way to finance labor and materials along the way.

TurtleSoft started out very, very easily. The first estimating template only took a month or two to write, during a slow winter spell in early 1986. Sitting at the computer was a welcome relief from swinging a hammer. Turtle Creek Carpentry made enough extra profits the rest of the year to pay for the time. In March 1987 we ran an ad in Fine Homebuilding to sell it, and the software business rocket-launched from there. You might say that the initial development costs were almost free.

As we expanded, each new MacNail module took about 1 year of programmer time. HyperEstimator took a year. BidMagic took 2 or 3. Those were good times, when a small investment in programming could create a massive amount of income. It wasn’t hard at all to finance new product development. The hardest part was dealing with exponential growth, and then, dealing with the plateau when it ended.

We wrote the first prototypes for Goldenseal in 1993, and started writing C++ code in earnest two years later. It was our first ‘real’ app, and a much bigger project than anything we had done before. The first estimates were 5 or 6 programmer-years. It eventually took almost twice that to get to version 1.0.

The first half went smoothly, with plenty of income from our older software to pay for the work. Then, in early 1997, Apple announced a $708 million-dollar quarterly loss. There was speculation the company would be swallowed by IBM or Sun, and Macintosh sales dropped almost to zero. More than half our sales were on Mac, and those disappeared.

The good times were over, and the second half of the Goldenseal programming happened on a shoestring. We couldn’t have finished it without loyal MacNail users who purchased pre-release versions (plus a lot of credit card debt).

Cash flow was tight at Turtlesoft until the release of Goldenseal for Windows in 2002. Then, for the next five years, net income became rosier than ever. Sales were better than the MacNail days, and support costs were smaller. Those were boom years for construction, and it flowed down to construction software.

However, we had learned a lesson about sudden loss of cash flow, and decided in 2005 to start a ‘backup’ business with steadier income, to offset the ups and downs of construction software. The result was SmartKnives, which sells Swiss Army knives and Leatherman tools (mostly purchased from airport auctions). It started out mostly as entertainment for the programmers, but as software sales declined post-recession, we ramped up knife sales.

Right now, SmartKnives is paying most of the bills, and funding the programming work on Goldenseal Pro. Running a second business does slow things down. However, programming work can be very draining (and fattening). There’s a lot to be said for doing it part-time. Cleaning and photographing vintage knives is a pleasant break from hours at the computer. 

Ever since the beginnings 30 years ago, our programming efforts have been very seasonal. October to April is the main programming season. We usually slack off or take a full break in the summer, and do outdoor things. Difficult problems often become so much easier after a couple months of being ignored.

As we did with the original Goldenseal, we have an option to pre-order Goldenseal Pro. It’s cheaper than the final upgrade price, and it helps prod us (and finance us) to work slightly faster. Most likely we will publicize it more (and probably raise the price) as we get closer to completion.

Dennis Kolva
Programming Director




Goldenseal Pro Tech Support (July 12)

As we modernize our code for Goldenseal Pro, it’s also an opportunity to update the rest of our software business. Right now we are thinking about tech support.

Our software has always included unlimited free support, by phone or email.

Naturally, it’s very popular with users, but it also helps us. Many of our new features and improvements come from user suggestions. And, even when there is confusion or a problem, it tells us what needs improving in the software design and documentation. The amount of support we need to provide keeps decreasing, as we gradually make our software easier to understand.

On the minus side, technical support is very hard work, especially when done over the phone. Helping frustrated callers requires tact, patience, technical skill, and a thick skin. It is hard to find all those together in one person, and even harder for any given human to keep it up for hours. Most callers are easy to work with, but some are difficult and draining.

As phone service switches from land lines to cells and VOIP, there is also a latency problem. The cellular network typically adds a delay of 90 to 200 milliseconds each way. That’s only 1 or 2 tenths of a second, but it’s enough to disrupt conversation ‘flow’. Staff and callers are more likely to interrupt each other, and seem rude or impatient when it’s really just transmission lag.

The other option, email support, has the big advantage of being asynchronous. You can send a message at 3 AM or whenever, and we can answer it without interrupting our other work. In an email reply, we can paste a link to an Answers page on our website, or copy text from there. We also have time to compose a thoughtful answer (and do testing or research if necessary), without you waiting on the phone.

Of course, email support is not perfect. The worst problem is the delay, which is annoying even if we answer at maximum speed. Also, some of our users are vision-impaired or dyslexic, and can’t work with text. Some support callers are just generally frustrated, and need a reassuring voice, rather than text. In general, we find that some problems are much easier to solve by email, and some are much easier via the give-and-take of a phone conversation.

Live support is a third option that is becoming more common: it is text-based, but more real-time than email. It’s better in some ways, but also has its flaws. It probably can’t replace either of the other support options, but it may be a reasonable supplement.

We have been looking at tech support provided by other software companies. In general, support usually depends on the complexity and cost of the program. Small, single-purpose apps (less than $100) rarely include phone support, and often have slow email turnaround. Large, enterprise software (more than $3000) usually requires an annual fee for support and updates, or pay-per-call.  In between, phone support is more often available and free, but it is becoming less common. What there is, often goes to an overseas call center.

We are not to the point of making any decisions yet, and would welcome user feedback on this subject.

Dennis Kolva
Programming Director