Ask HN: What is my app missing? | Hacker News Reader

Ask HN: What is my app missing?

7 pointsDaveChild12 comments

I have set up a simple and cheap bug tracker and work management app, and am hoping for some feedback. It's similar to a stripped down JIRA - just the main features, without the plugins - and at a reasonable price, I think.

I've been running a low-key free beta for a while, and have had a few signups (I've not charged anyone yet, so no paying customers), but most don't seem to use the tool. They sign up, then are never seen again.

I'm not sure if it's just that this type of tool ends up generating a lot of people who are just taking a look, and very few usually carry on to use it, or if there's some serious problems with the app.

I'm not anything much in the way of "not seen you for a week" or "how are you finding it" emails - working on those next.

I've emailed most of the signups over the last week to try and get some feedback (and get a few of the older signups to have another look), and have had a few responses, most of which were positive. Suggestions were, I think, relatively minor things like image and line break support directly in the WYSIWYG.

The app is at http://www.envoyapp.com and there's a demo at http://demo.envoyapp.com

I've most recently added the API and FAQ.

I would have thought most of the lovely folk here are the kinds of people who would use this sort of thing, so perhaps the best possible people to point out the flaws!

[P.S. The server is a small, beta-size setup so if lots of HNers turn up at once the site may vanish. I'll be keeping an eye on it as best I can today.]

Selling tools to tool builders is a tricky proposition.

Apps like these sell to enterprises (large and small). You are almost certainly talking to the wrong people (although I am sure potential users looked like the right people to start with).

Tell the world just what problem your app uniquely solves and see what happens.

N.B. You will need to convince enterprises (start-ups etc.) that you are there for the long term and that your infrastructure is secure, robust and 99.99% available.

Good luck.

> Selling tools to tool builders is a tricky proposition.

Indeed! We're a fussy lot :)

All good points about reliability - I'll see what I can do to add that reassurance to the setup.

Uhm you made an interesting point, would you mind expanding it? Where should he look for customers? He is on Hacker News now, don't you thin it's a nice place to find the people he need?

Yes - the point I was trying to make was the "pitch" needs to be to the enterprise while the functionality needs to meet the needs of the developers/support people who would actually use it.

I think that this is a tough thing to get right.

Feedback from HN users is going to be difficult to "filter" as we are mostly developers yet some of us are also (of necessity) business types. [Edit] When I said "talking to the wrong people" I was not referring directly to this post on HN.

It's attractive and clean, which is refreshing compared to JIRA. I like your Office Space demo.

Maybe your problem is your market. Established development firms use JIRA or something else. They may be hooked on some of the big features that are part of the tool's complexity.

There are still businesses out there that have never heard of things like agile, or source control, and who manage projects by sending emails back and forth. Identify them and go after them. This may be all the tool they need.

My not totally practical advice? Get a job at a temp agency. You'll find your customers.

I'm speaking from experience. I have temped a few times in between jobs. Stapling and filing papers and all that. For small and medium sized companies that we tech people just don't think about - chinese graphite importers, freight forwarders, etc.

After a few days I'd start noticing things that I couldn't believe they were doing or using. "Why do they do it like that? Haven't they ever heard of process X, tool Y, technology Z?" Once in awhile I would even suggest something and help them out. It even landed me a bit of contract work on the side once.

I think there's a world of customers we're just blind to that aren't prejudiced to the existing tools, who might be persuaded into trying your software.

> There are still businesses out there that have never heard of things like agile, or source control, and who manage projects by sending emails back and forth.

That's pretty much my target. There are tonnes of small agencies and small ecommerce outfits (especially in the UK) that aren't using anything to manage bugs or work. The problem, of course, is finding them.

Interesting idea, the temping thing. I suspect some simple freelancing might have a similar effect.

I'm rather hoping, though, that my blog and cheat sheets (at addedbytes.com) gives me the exposure to the kinds of people who might be interested in this type of product. It's clocking up 200,000 page views a month or so, and that's almost exclusively developers and ecommerce types. I'm hoping a series of blog posts on the topic of bug tracking will help a few lost souls out of the email and spreadsheet bug-management quagmire!

Thanks for the compliments. Glad you like the look - I was going for simple and clean.

How do you compare to fogbugz and its philosophy?

I mean to invoke some reflection about this.

We hold fogbugz up as the sweet spot of get-things-done bug-tracking.

(As a JIRA user at work, I can say that the JIRA and bugzilla report-centric mandatory-required-fields-and-flow-centric approach is a horror to use, unless you're the manager)

http://www.joelonsoftware.com/articles/fog0000000029.html and think about how you can interact with fogbugz using email, how its free-form without required fields or custom flow and so on.

I think it's fairly similar, at least in philosophy. I always liked some parts of FogBugz - minimum number of required fields, always one owner and making it as easy as possible to get bugs in to the system from multiple places - and those all things I continue to think are important, and have tried to get in to Envoy. Ease of bug addition is critical, as without it you can't get management to use the system and it fails, so all accounts automatically have an email address they can use to send in bugs. I'm looking at ways to use the API to tie into other systems too to make the addition of bugs as easy as possible from other places.

Clickable links:

http://www.envoyapp.com

http://demo.envoyapp.com

~~ Also, some wavy line background ... ~~

The app started, as I suspect many do, with me wanting a simple bug tracker, timesheet and wiki app for managing bugs, time, etc. I'd used FogBugz, JIRA and a few others (and their influence is probably obvious) and wanted something similar, but that I could tinker with.

So, I built the thing I wanted to use, and have been using it myself for a few years. Over time I've added things as I found I needed them. Some of those things have stayed, some have been dropped after finding they didn't work the way I thought they would.

I was using it at work, and others were finding it useful and asking if they could use it too, so I decided to see if it would be useful to other people, and grew it into what it is now.

Monetizing an issue tracker will likely be Enterprise Sales. Are you sure you want to compete in an Enterprise Sales market against established players and hundreds of free options? From personal experience: It's not going to be fun and you will very likely fail.

Thanks for the honest feedback. I know it's a hugely competitive space, and I'm hoping that the bootstrapping and low-cost approach means I can turn this into an income-level project, rather than perhaps a full-on company.

I cross-posted this to reddit, cos I like it there too:

http://www.reddit.com/r/webdev/comments/vmo71/envoy_a_simple...

Reply on news.ycombinator.com