Nine months into selling our first web-based product, DoneDone, we've learned a lot of lessons. Bugs, even the most hidden and seemingly dormant, are eventually found because people are using your product all over the world at all different times of day.

One of the big lessons we've learned is how we program against third-party services. Like most small businesses, we can only build so much software. Using third-party tools is crucial - particularly on the onerous things that aren't unique to your software. In our case, we are currently using the Rackspace Cloud to host uploaded files and Zuora to handle billing. They are both crucial components of our software that we simply don't have the time to build ourselves. And, having third-party services strictly dedicated to specific tasks (like file hosting or recurring billing) means we're almost always in good hands.

The downside to third party services is you're somewhat at their mercy. If our billing system goes down or uploads aren't working, it's a phone call or a ticket submission and a waiting game. There's no opening up an IDE, finding the leak, compiling, and pushing a quick update.

But, there is something you can control - how your application handles the occasional broken external service. While it should seem like programming 101, we initially didn't handle exceptions from our third-party services very well at all.

At one point, if our billing service was down, it actually meant you couldn't even login to DoneDone at all. Whenever you login to DoneDone, it checks the account status by hitting an internal service we have called WAMBAM (We Are Mammoth Business Account Manager). Only a small subset of the methods in WAMBAM require talking to Zuora, but we were logging into Zuora each time we made a call to WAMBAM. So, if Zuora servers were down, so were we. An unfortunate, yet entirely easy mistake to make.

We recently had a similar issue with the Rackspace Cloud. Their API was down for approximately an hour last week, but it inadvertently caused issues with submitting a bug, even if you weren't uploading anything. Again, we were accessing the third-party when we needn't be.

We could pit the blame on third-party services. From our perspective, they should never go down! But, they do. All things break down now and then. We needed to do a better job of handling problems when they have problems. It's too easy to make the mistake of not catching exceptions properly from third party apps. It's also crucial to only call third party services when you absolutely need to.

When you couple the fact that your third party services are probably, in turn, using other third party services (and so on) it's everyone's duty to make sure their apps run as smoothly as possible when things out of their control go down for the count.

Labels: DoneDone

Eat Media is a no-nonsense content development company with a passion for writing. We recently asked Ian Alexander, Vice President of Eat Media, to talk to us about how DoneDone has helped them get stuff done.

On DoneDone's intentional simplicity...

I appreciate the "talk to me when I need to be talked to" aspect of this software. It cuts down on the too many cooks in the kitchen issues.

I've tried almost all of them from using MS Project to Bugzilla, Fogcreek software (FogBugz), custom developed, Dynamsoft, Excel and many others I happily forget the names of. I think I have been on the hunt for DoneDone since 1997 or so.

Why did I switch? Because it works and people use it. Those are really the two must haves for bug tracking. The umpteen other features are unnecessary for 90% of the projects we do and have done in the past.

On DoneDone's pay-per-project, rather than tiered, pricing structure...

Dig it. Our company utilizes many of the best-in-breed SAAS model systems to run our operations. With multiple offices and hundreds of vendors to manage we have to take advantage of scalable online systems to stay competitive. The pay-per-project aspect and ability to cancel at any time definitely helped me try out the product.

On how it's helped create order out of potential chaos...

The end of a project is a time when clarity is of the utmost importance. If one person is emailing you daily and another is sending you Excel sheets at the end of the week, and yet another is exporting out of their internal bug-tracking system that an intern built in FileMaker Pro over the summer in 2001...and you're not using DoneDone, you're in trouble.

On what makes DoneDone stand out...

Almost everyone has said, "This is the perfect bug tracker." In my experience, the biggest hurdle with most bug tracking systems is getting people to use it.

We use DoneDone for almost all of our external projects, especially those that relate to digital deliverables. I cannot imagine trying to manage external resources in the middle and end of projects without [it]. Simplicity sometimes has a negative connotation but with Donedone the simplicity is incredibly empowering.

Follow Eat Media on their blog or on Twitter. Thanks for the feedback Ian!

Labels: DoneDone

This evening, we released a big, albeit subtle, change to DoneDone issues: You can now assign an issue back to the creator of the issue.

Since the beginning, we've always avoided allowing this capability. We felt it went counter to how a bug tracking workflow should work. The problem we had with other bug tracking tools was that there was never an automatic assumption being made between the state of the issue and who should be working on that issue.

So, if John assigned a bug to Jane, and Jane had a question, she'd have to ask the question, potentially change the state of the issue ("Missing information") and then re-assign the issue back to John. Our gripe was that the application should let John know he needs to respond to Jane's question before she could continue working on it. With DoneDone, changing the status of the issue also determines who acts on it next.

Our worry was people would just assume they had to keep re-assigning the issue back to the creator if they had a question, or wanted the bug to be tested, etc. when this is not the case. The issue statuses determine who should act next.

Many of you, by emailing us, tweeting, or posting on our forum on GetSatisfaction, came up with some valid use cases where it really would help if we simply allowed the feature. Zak posted a couple of great examples on GetSatisfaction, where assigning an issue back to the creator makes complete sense:

Developer-A creates a bug and assigns it to Dev-B. Dev-B decides she doesn't have time for it and wants to assign it back to Dev-A (who is perfectly capable of fixing the bug himself).

And another: Dev-A creates a bug and assigns it to himself. After making progress he gets stuck and decides Dev-B should take over. Then, after staring at the code for 5 minutes, Dev-A finds the solution and kindly asks Dev-B to assign it back to him.

....Currently this restraint seems to do nothing but punish developers for taking initiative and logging their bugs as they find and fix them.

After enough internal debate, we've finally decided to allow this feature. If you are the issue creator, issue resolver, or an admin, you can re-assign any issue back to the person who created it. In the case where an open issue is in a state other than "In Progress", or "Ready for Next Release" the issue goes back to the "Open" state - self-assigned issues can only be in those two states.

We hope you find this new addition helpful, and understand why it took us so long to get it in. Thanks for your continued support!

Labels: DoneDone

Last week, we added an API documentation page to DoneDone. You can now get more detail about the available services and answers to common questions at: http://www.getdonedone.com/apiinstructions.aspx.

In our next release, we'll be rolling out a bunch of new services through the API as well. You'll soon be able to reassign an issue, change issue status, and close and re-open issues through the API. Stay tuned for details coming this week.

Chris Hardy (aka ChrisNTR) built a DoneDone iPhone app using MonoTouch recently.


How are you using the DoneDone API? Send us a message or comment back. We'd love to find out how we can improve it.

Labels: DoneDone

I use Apple's Mail and iCal to keep my schedule organized and to keep a hold on the multitude of things that would otherwise get lost in the ether of my mind. If it doesn't come through one or both of those programs, the chances of it slipping through the cracks are extraordinarily high for a person like me. I (mostly) subscribe to the Inbox Zero philosophy and so I try to take action on emails as they come in so that I can ignore the things I need to ignore and do the things I need to do. I especially like using Mail's Todo section to keep track of all the things that I know I'll have to do, but can't take care of right at the moment I am notified about them. Because of this, I've written a little Applescript which I trigger via Mail's rules to automatically add a Todo item to my list whenever I get something from DoneDone that requires my attention). You can download it here. This script will watch for incoming messages from DoneDone and either create or check off issues in your Todo list based on whether the issue requires your attention or has been marked as completed in DoneDone.

Before you set up your rules, be sure to modify the script above by replacing "YOUR CALENDAR NAME GOES HERE" with the name of the actual calendar you want to keep your todo list on.

Here's a rundown of my rules setup:


1. All conditions must be met.
2. From contains "@mydonedone"
3. Subject does not contain "- New comment"
4. Subject does not contain "- Response to"
5. Run the script above.

It isn't much, but for naturally disorganized people like me -- every little bit counts.

Labels: DoneDone

Last Wednesday, we updated all DoneDone accounts with a bunch of long awaited updates. It's been a little over a month since we launched a major update to DoneDone, so we're excited this has finally passed. Here's what's new:

Issue management for administrators
We now allow administrators more control over all issues within a project. Admins can now do the following on any issue in DoneDone:

• Change the priority level of an issue
• Re-assign the issue to another person
• Close (or re-open) any issues

If you're an admin, you'll notice a new label at the top of each issue detail page displaying the current mode of the issue. By default, all issues appear in normal mode.


If you want to change the priority level, re-assign, or close/re-open any issue, click the "Switch to admin mode" link. The issue will then refresh in admin mode. Clicking the link again will return the issue back to normal mode.


We know many of you have been waiting for this feature for a few months. We spent weeks contemplating how to best modify the interface while adding as little visual clutter while making it clear when you are (or are not) in admin mode. Hopefully this does the trick. We appreciate your patience!

Linking to other issues in your DoneDone project
We've had a few requests to allow linking between related issues. Now, you can link an issue to another issue within a comment or description by simply typing in the issue number with a # sign. If the issue exists, DoneDone will create a link to that issue.

We aren't the first ones to have adopted this convention. Garret Dimon's post here explains why this feature is used in Sifter, and we couldn't do a better job of explaining why.

New additions to the API
We've added the following capabilities to the API. We hope this gives you greater flexibility in creating third-party apps for DoneDone:

• GetIssue lets you get the details of a particular issue (create date, update date, title, description, creator, resolver, status, project id, files, history, and tags)
• GetIssuesInProject allows you to get all issues in a project. By default, all details of an issue are returned but none of the history. You may optionally choose to load history as well (comments, status changes, etc) for each issue, though expect this to potentially take awhile.
• CreateIssue lets you pass in a string array of tags
• CreateIssue also lets you create an issue on behalf of someone, if you are an admin.

Add tags to bulk loaded issues
Last month, we released a new feature - bulk upload issues using a CSV file. We now allow you to optionally include a comma-separated list of tags for each issue. For more information, click the "Import issues using CSV" link at the bottom of a project's home page.

We hope you enjoy these new features. As always, let us know how you're feeling using our forums page at GetSatisfaction, connecting with us on Twitter, or emailing us.

Labels: DoneDone

We have some updates coming up for DoneDone in the next release. While we don't have a firm date set yet, it will very likely be within the next two weeks. Thanks to everyone for the feedback so far.

Deleting issues (for good)
For a long time now, we've been telling you to simply close issues to get rid of them. But, many of you have requested a true delete of an issue. In the next release, every person can permanently delete issues they've created (administrators can delete anyone's issues). Deleting issues will remove them from DoneDone for good. They won't show up in status reports or the "closed" issues bucket.

Here's what the issues page will look like with the new "delete" button. We're still tinkering with its location...


Importing issues
Many of you have requested a better way to transfer issues from another bug tracker into DoneDone. In the next release, we'll allow you to bulk load issues for a given project by uploading a CSV. You'll be required to provide a column for title, creator email address, and resolver email address, as well as optionally include columns for description, create date, and priority level. Each row in your CSV will be converted to a new issue in DoneDone.

DoneDone will parse each row of your CSV file and add an issue. If something is wrong with a particular row (i.e. we couldn't match an email address to a person assigned to the project, required fields weren't provided, etc.) DoneDone will skip that row and move to the next one. At the end, you'll see a full report of which rows were successfully inserted as issues as well as which rows had problems.

Labels: DoneDone

We made a small tweak to issue lists in DoneDone today.

Previously, things worked like this. You'd go to a project and search for issues. You'd click into an issue to view the detail. You could even click the "Previous Issue" and "Next Issue" links in the upper-right to scroll through the issues you searched for. But, as soon as you clicked "Back to My Project", your old search was gone.


Now, when you click "Back to My Project", we'll take you back to the last search you did for your issues so you don't have to search for the same set of issues again. We hope this makes things a bit more convenient.

Labels: DoneDone

This weekend, we made an update to DoneDone to better support removing people.

Previously, when you wanted to remove someone, we'd also remove all related issues that were created by or assigned to that person. It was an early decision in the design that no longer makes sense to us. If a person leaves your company, it's unlikely that his or her issues magically don't matter anymore.

Now, when you want to remove someone, DoneDone checks if there are any issues related to that person. If so, you can move all these issues over to either someone in your own company or the company that person worked for (if it's a different company).


The new person in charge of these issues will be notified by email and you'll see a note about what happened in each issue's history.

We think this is a great feature that you hopefully don't have to use too often!

Labels: DoneDone

This week, we'll be adding Google Analytics tracking to all DoneDone accounts. Here's why we're trying this out. We hope it answers any questions you may have about our decision.

We launched DoneDone 3 months ago last Wednesday. It's been a veritable whirlwind of feedback, feature requests, questions, responses, open dialogue, and software improvements. We think DoneDone is a much better tool now than it was even a month ago because of the great feedback we've been getting from a passionate customer base. And, for the forseeable future, we'll continue to respond directly and quickly to you guys. We take customer service very seriously.

But, we're also past that honeymoon period we were in a couple months ago when we had just a handful of paying customers. Back then, we felt we could pretty well guess what DoneDone was missing or not doing quite as well. We've had a laundry list of things we wanted to add post-launch, and much of that list is now checked off. Every decision we make now, whether it's adding new features or tweaking existing ones, comes at a much higher risk as our user base grows.

Why Analytics?
So, we want to use Analytics to get a better sense of how people are using DoneDone, what's working, and what's not working. Using this data along with the input from those of you who write us directly, we think we can make better judgments on what needs to be tweaked or added.

What exactly are we looking at?
For those of you not familiar with Google Analytics, rest assured that we won't be sending over or seeing any sensitive data in our reports. Nothing about our privacy policy will change.

We'll be able to see what pages are being accessed (an issue detail page, a project home page) but won't know what these pages contain. We'll also be tracking what percentage of you are using vCards and RSS feeds, but we won't know anything about what it contains. Analytics will give us a general sense of what's being used alot and not a whole lot so we can make better decisions down the road.

What we're doing to ensure your privacy.

• We've disabled all options for sharing data with Google Analytics
• By default, all DoneDone accounts run under SSL. Likewise, we are sending across all information to Google from SSL-enabled accounts through SSL as well.

If you have any questions or concerns, you know where to find us.

Labels: DoneDone

This evening, we launched three big enhancements to DoneDone. We hope they make getting issues solved even easier.

Tagging issues
You can now add tags to new and existing issues. We think tags will be useful because they're so open-ended. Decide amongst your team how you might use them to categorize bugs better. Here's just a few ways you might want to use tags to help organize your issues:

• Tag issues by discipline ("Design", "Development", "UI", etc.)
• Tag issues by browser type/OS ("Firefox", "IE", "Safari"/"OSX","Windows","Linux", etc.)
• Tag issues by type of issue ("Feature request", "Phase I bug", "Phase II bug" etc.)
  
• Tag issues by categories specific to your project ("Products", "News", "People", etc.)
• Tag issues by what version it should belong in ("1.0", "1.1", "1.2", etc.)
• Tag issues by when they're due ("July 18th", "August release", "3rd quarter", etc.)

If you want to add multiple tags to an issue, separate them by a comma. DoneDone will bring up a list of other tags you've used on the project as you're typing:

On an issue's detail page, they appear on the upper right. You can click on any tag to find all other issues having the same tag.


Finally, you can search tags. Just type in the name of the tag in the "Search for" input box (which also searches for matching text in issue titles and descriptions). We've also added them as another searchable item in the custom search panel. You can search for one or many tags in your custom search.



Email-to-ticket: Submit new issues through email
You can now send new issues to a unique email address for each project in your DoneDone account. You can find the address at the bottom of each project's homepage. We've also included a vCard if you want to file the address away in your desktop email program.

Do note, there are a few limitations with email-to-ticket. You cannot upload files nor can you tag issues through the email-to-ticket feature. The "creator" of the issue must be the person whose email address is tied to the email address you are sending from as well.

Read more detailed info about email-to-ticket in our FAQ section: http://www.getdonedone.com/faq.aspx#issues_4.

Attachments revamp
We've also modified how we display attachments on the issue detail page.

Previously, in the issue detail section, you would just see links to attachments that were initially uploaded with the original issue. If anyone added attachments to a comment later on, they only appeared in the history section below. This made it a little less obvious to track what files were still relevant.

Now, we include all attachments in the "attachments" section of the issue detail page. Those that were uploaded with a comment have a timestamp next to it. If you click on the timestamp, you'll scroll down to the comment related to that attachment.


Keep bugging us...
We do hope you enjoy these new features. They were on the top of our priority list for awhile, and we worked hard to get them up and running as soon as possible. As always, let us know what you think! Follow us on Twitter @getdonedone.

Labels: DoneDone

We've been working on two big features to DoneDone. We'll likely launch these sometime next week once we've tested and are 100% happy with the UI. Here's an early preview.

Tagging issues
Soon, you'll be able to add tags to your issues. Many of you have requested this, or requested something that this feature will help solve. We think it adds the right amount of flexibility to DoneDone without sacrificing simplicity.

Tags are useful because they're so open-ended. Here's some ways you might want to use tags to help organize your issues:

• Tag issues by discipline ("Design", "Development", "UI", etc.)
• Tag issues by browser type/OS ("Firefox", "IE", "Safari"/"OSX","Windows","Linux", etc.)
• Tag issues by type of issue ("Feature request", "Phase I bug", "Phase II bug" etc.) Note: you can modify an issue's tags at any time, so these might be decided upon at a later date.
  
• Tag issues by categories specific to your project ("Products", "News", "People", etc.)
• Tag issues by what version it should belong in ("1.0", "1.1", "1.2", etc.)

You can add any number of tags to an issue and you'll be able to search all issues by the tags you've created (we haven't finalized the UI for that just yet).

By keeping tags simple and flexible, and letting you add as many or as few to your issues, we're letting you define how your project should be organized. It's all about what works best for you.

Submit an issue through email
We're in the final phases of testing our email-to-ticket system. It will allow you to send emails to a project-specific email address on your DoneDone account to create issues. You'll be able to assign an issue to a user (based on their account email address), set priority, and create a title and description. The format of the email will roughly look like this:

To: addIssue+MyCompany+28@mydonedone.com
Title: I cannot login on the homepage -----------------------------------------------
john.doe@mycompany.com
Critical
When I try to login with my credentials, I get the message "your username and password are incorrect" but I'm pretty sure they're correct!

The first line of your email body will be the email address of the person you're assigning the issue to. The second line will be the priority of the issue, and all lines after that will be the description of the issue.

Email-to-ticket will not let you add tags or attachments (at least not yet).

Stay tuned for these upcoming additions!

Labels: DoneDone

In an upcoming scheduled update to DoneDone, we've tweaked the issue detail page interface a bit. There isn't any new functionality, and these aren't big changes, but they're important enough that I want to discuss why we did them.

What it looks like right now
Currently, when you look at an issue detail page, you see three basic sections:

• Issue information and next possible actions (in light blue)
  
• Comment box (in gray)
  
• Issue history (at the bottom)
  

We're finding alot of our users (and some of us) get distracted by the comment box. If you've been assigned an issue, more than likely your first move should be to change the status of the issue to "In progress", "Not reproducible", etc. Changing issue statuses is core to our philosphy - it moves that issue to the appropriate person's bucket. We want that to be the first step people take.

From your feedback, we get the sense that you see the inviting comment box and immediately want to type into it:

New comment: "Hey, I can't reproduce this issue on my browser. Are you using Mosaic again?"

Here's the problem. When you add comments, you're not changing the status of the issue. Really, this should have been a status change to "missing information" and the comment should go in the yellow box. Comments should only be used if you're just making a note about something, or adding to the issue without the intent of changing the status.

The other problem is, the exposed comment box is pushing the issue history further down the page. The comment box is simply getting in the way. We need it to take up a more appropriate amount of space relative to its general importance.

Our attempt at solving the problem
We're going to do two things to guide you a bit more.

First, we're hiding the comment box and showing a link to "add a comment" instead. The link just exposes the comment box.

Second, if you are assigned an issue, you'll see the "change status" dropdown and comment area open by default. Here's what the new version of the same page will more-or-less look like:

A follow-up thought on usability
While we like the changes, there are potential drawbacks. You now need to make an extra step to add a comment. It might take new users an extra few seconds to figure out how to add a comment.

But, these minor gotchas are risks we're willing to take. I don't think there should be golden rules in usability (less clicks is always better than more clicks, in this case). In our case, making something slightly harder or less obvious is, in turn, making the more-likely-to-be-correct-action easier and more obvious.

We hope this slight UI change makes sense and you think it's the right change. We'll likely be making the update sometime early next week. Comment back or hit us up on Twitter (@getdonedone).

Labels: DoneDone

This week, we released a simple status report page for all DoneDone projects. We want it to be a quick overview instead of a detailed report. We want you to glance at it for 15 seconds and know how a project's generally going.

To get any project's status report, click the "Status report" link at the top of a project homepage.


The status reports page answers the two questions we think are most important:

1. What percentage of issues have been completed?
2. How much is on everyone's plate?

The first answer is pretty self-explanatory. We just take all closed issues and divide them by all created issues to get a completion percentage. Nothing big, but knowing that 93% of issues are completed tells you that you're definitely looking downhill.

The second answer reinforces what we want issue tracking to be about. Who's responsible for what, right now? Who's waiting on what? Just like in your dashboard, a project's status report shows you a grid of each person's items waiting on them and items that they are waiting on. You can also click a box to go right to those issues.

If you have multiple companies working on a project, you can choose them in the dropdown to the right.


As always, let us know what you think! Twitter @getdonedone or post a comment.

Labels: DoneDone

Recently, Bug Shooting added support for DoneDone. Bug Shooting is a free download for Windows that lets you take screenshots, annotate them, and immediately upload them as part of a new or existing issue. Do note that we currently only allow file uploads for paid accounts.

Here's how it works with DoneDone.

Quick install and setup
After you install Bug Shooting, you need to set up DoneDone as a server. Right-click the bug icon in your desktop tray, and go to Options > Settings > Server. Choose DoneDone, and then enter in your DoneDone URL and credentials.


Say Cheese!
To take a screenshot with Bug Shooting, you can either double-click the icon in your desktop tray, or you can configure it to launch when you hit your "Print Screen" key. Bug Shooting will launch with your screenshot and let you draw and add text.


You have a couple options to post the screenshot. You can either create a completely new issue or add the screenshot as a comment to an existing issue. To make a new issue, leave the "New Issue" option selected. To add the screenshot to an existing issue, enter in the issue number (you'll select the project later). You can also add text into the "Comment" field, which will make it the title and description for a new issue, or a comment for an existing issue. Make sure you've picked the DoneDone server, and when you're ready, click the "Send" button.


Send 'er away!
Once you hit "Send", Bug Shooting will connect to your DoneDone account. You'll get a popup where you can select the project, priority level, and person to assign this issue to. Do note that only projects that have the API enabled will be selectable. Account admins can go to the project settings page in DoneDone and click the "Enable API Access" button.



Once you've submitted your issue, you'll get redirected to the issue in DoneDone.

Special thanks to Alexej at Bug Shooting for so quickly adding DoneDone support!

Labels: DoneDone

We just released two big functional changes to DoneDone today as well as a big pricing change, mainly inspired by our users (cuz we listen!). We'll post an alert to your account homepage when these changes take effect. Here goes....

Functional Change #1: Assigning an issue to yourself
You can now assign issues to yourself. When we launched last month, we didn't permit this because one of the core features we wanted to expose was how DoneDone pushes an issue to the appropriate person ("Issues waiting on you v. Issues waiting on them"). We anticipated most issues would be assigned by someone and resolved by someone else.

But, we're finding out that many of you like to assign issues to yourself. In fact, on our own client work, we've wanted to a few times as well and had to workaround it.

So, now you can assign issues to yourself. There are a few changes to how self-assigned issues work (vs. normal issues):

• For self-assigned issues, the statuses "Not an issue", "Not reproducible", and "Missing information" are gone. It doesn't make sense to have those available if you created the bug for yourself.

• If a project has release builds enabled, you can set a self-assigned issue to "Fixed for next release." Basically, this is the same as "Ready for next release" with the caveat that, once the release build is done, that issue is automatically closed (since you're the one testing the issue).

• You will not receive email updates on the issue (i.e. you won't get an email saying you changed the priority of the issue, since you're the one doing it). You can, however, still add comments to the issue and have those emailed to you.

• Finally, all self-assigned issues will always be in your "Issues waiting on you" bucket, until you've pushed it into the next release or closed it. In other words, you won't ever have a self-assigned issue in the "Issues waiting on them" bucket.
  

Functional Change #2: HTML tags in issue descriptions and comments
You can now type in HTML tags into an issue's description and comments box. They'll always display as actual HTML source code on the issue detail page and in emails. Really handy for describing code bugs to someone.

Pricing Change: Things just got cheaper....
We're restructuring our pricing plan. Before today, you paid $24/month for your first project, and then $5/month for each additional project.

Now, you'll pay $15/month for up to three projects, and just $2/month for each additional project. The most you'll ever pay is $99/month (which comes out to 45 projects). You can add on more than 45 projects...but we won't charge you. Here's an infographic:


Why the change? Much more detail here.

All existing accounts will be automatically converted to the new plan on your next invoice in June.

Labels: DoneDone

We're rethinking our pricing model for DoneDone, our web-based issue tracking tool, and want to open up our entire thought process, lessons learned, and epiphanies to you.

Our current pricing plan is simple: You pay $24/month for one project, and then $5/month for each additional project.

When we launched last month, we asked some of our early customers what they thought about our pricing. We got some great feedback. Everyone had slightly different ideas. Then we stopped asking and thought what is this thing really worth. Finally, I read Joel Spoltsky's article on software pricing. He recommended the following:

"Take my advice, offered about 20 pages back: charge $0.05 for your software. Unless it does bug tracking, in which case the correct price is $30,000,000. Thank you for your time, and I apologize for leaving you even less able to price software than you were when you started reading this."

We're now certain that somewhere between free and $30,000,000 seems like the right price point. Mark our words.

Why we chose a linear pricing model
We chose to price DoneDone on a per-project basis (linear) rather than on the far-more-familiar tiered pricing method. That's because we guessed most companies attracted to DoneDone would be in the same boat we're in: A small shop with only a few projects in QA at a time. As a quick comparison, we have 30+ projects open in Basecamp at any given time, but only one or two are in a true "testing" phase.

By charging per project, you only pay for what you use - and you can always archive a project as well. Archived projects are free.

Why not do the tried & true tiered model?
We're against the tiered model because we didn't like the big "steps" up to a new tier. Having tiers by project (e.g. 1 project for $, 10 projects for $$, 25 projects for $$$, and 1,318 projects for $$$$$$!) didn't make sense if our hunches were correct. If most companies indeed would only have a couple projects active at a time, the leap to a plan with a bunch more projects would never make financial sense to them.

But, we've gotten a bunch of mixed reviews about our linear model.

For one, it's a different model than what most of our competitors use. And, it's probably not a great idea to be innovative with something like asking for people's money when virtually everyone selling web-based software is doing that same tiered-pricing thing. (Plus, it's the one time you can legitimately make a table in HTML without your HTML buddy getting-all-up-in-your-$hit).

There's potentially a lesson in this, though. We should be weary about forcing our hunches into the pricing model. Perhaps sticking with a cost structure that's tested with apps roughly similar to ours (but not necessarily how we think people will really use DoneDone) is a better way to go. Perhaps.

Also, part of the beauty of the tiered model is that bit of marketing sleight-of-hand:



How some of our competitors are pricing
If we're wrong on our hunch, that companies do want the flexibility of having a bunch of projects open at a time, then our current pricing cost flat out sucks compared to our competitors. There are about 8 billion bug/issue trackers on the market. Here's how we currently compare to a couple of comparable competitors, Sifter and Lighthouse:

In the beginning, our model falls in line with the other two. But as we add more projects, things start to go bad quickly. Again, given our assumption that people only have a few active projects at a time, it's a non-issue. Get anywhere above 10 projects and things quickly start lookin' down for us. The m part ($5) of our "y = mx + b" needs to change. So does the b ($24). Finally, we don't have a natural cap on the cost because we didn't think that would ever rear it's ugly head . Yes, if someone has 1000 projects, they'd be paying...$5,019/month. But is that ever realistic? Probably not. But, from a quick glance, the never ending orange slope looks like a rather ominous predicament.

Why we like linear pricing over tiered pricing
A bit ago, I said we should be weary about burying our philosophy into the pricing model. But, we still think a linear model still has its advantages to the tiered model, particularly with something like issue tracking.

Where the tiered model "hurts" is at the beginning of each tier. With Sifter, you're paying as much for 11 projects as you are for 25. You're paying as much for 26 projects as you are for 50. While our guess that people will use DoneDone for only a few active projects at a time might be wrong, assuming a company hovers around a sweet spot of active projects is probably a safe assumption. For us, that sweet spot might be...2. For a different company, it might be 8 or 15 or 24. Who knows.

If you happen to hover around a tier, you're in a bit of a conundrum. Go down a tier and you have to worry too much about hitting your limit. Go up a tier and you might be paying double for just one or two more projects.

We still like the linear approach. It holds to our philosophy, but it probably needs some tweaking. We need to make it more competitive and advantageous for you.

Sticking with our approach with some tweaking
What have we learned? We like our approach in theory but a few things need to be changed:

• Charge less up front.
• Make the incremental slope more gradual (each project should be alot less).
• Put a cap on it.

Instead of charging $24/month up front and $5/month for each additional project, we're thinking of tweaking the initial cost to $15/month for the first 3 projects, then $2/month for each additional project. We also want to provide a cap at $99/month (which happens to be 45 active projects) to assuage the fears that costs can get unreasonably high. We still don't think too many companies will get to that level - and if they do, it really doesn't hurt us to cap the cost (storing that extra data is cheap). Let's see how this quasi-linear approach works:

Now, we're far more competitive and, overall, more advantageous by sticking to the linear approach. Admittedly, we're still charging more (on average) than Lighthouse does after 20 projects. But the benefit of the linear approach is the cost-hits are always incremental.

If our second hunch is right, that most companies will hover around a set number of active projects at any given time, the natural peaks and valleys a company experiences throughout the year won't drastically affect cost. In a tiered plan, if you're hovering near a tier (say you have 22 Sifter projects or 38 Lighthouse projects), you need to consider the cost hit of the next big tier.

Will this work better?
We think it does. But, because we don't want to charge like everyone else, there's more 'splainin to do.

It's easy for someone to see our approach and not like that there's a per-project charge (albeit, after 3 projects in this new model). But, when you really break it down, we hope you see where we're coming from.

We'd love to know your thoughts.

Labels: DoneDone

We've had some sporadic downtime this morning for about 45 minutes with DoneDone accounts (unrelated to any traffic spikes from the kind mention from 37signals). We're working to ensure that the issue doesn't happen again. It's a third-party thing....

In the meantime, we've gotten a ton of great feedback and questions regarding our philosophy and pricing behind the app in our first month since we released. Watch for some heartfelt posts on DoneDone topics here in the next couple of days.

Labels: DoneDone

Today, we added a few new features to DoneDone. This is our first upgrade of our issue tracking tool since we launched on April 15th. Here's what's new:

Toggle whether an issue comment is emailed to people.
Previously, if you added a comment, it would automatically email the other person on the issue. Now, we let you choose not to (i.e. if you just wanted to add a quick note to the issue and don't want to disturb the other person).

Adding additional recipients to release builds.
Before today, only the people who created issues in a release build were emailed that their issue(s) are ready for retest. Now, you can now pick other people to add to the email list (not just the people that have to test the issues).

"Ready for next release" doesn't stay waiting on you.
It used to be that if you fixed a bug and marked it as "Ready for next release," it would stay in your list of issues waiting on you. Many of you found this annoying...so did we. Now, any issue marked "Ready for next release" does not belong as either an issue waiting on you nor them. When an administrator creates a release build, the issue will then be waiting on the creator to confirm the issue is resolved.

Adding a comment to an issue via email.
When someone posts a comment to an issue, the other person will receive an email with the new comment (this is now toggle-able as you saw above). Now, you can simply reply to the email to post back a new comment. This makes having a conversation within an issue more natural...there's no need to constantly log back into DoneDone to do this.


RSS feeds (Welcome back 2005!).
You can now subscribe to RSS feeds on a global, per-project, or individual issue basis. There are RSS links on the footers of the dashboard, project home page and also on each issue page. RSS feeds require you to login with your DoneDone credentials. This is a great way to keep up with your issue lists from your own RSS reader.

We hope you enjoy the upgrades, and keep coming to us with new ideas!

Labels: DoneDone

Here are a few things we're working on with DoneDone. We don't know exactly when they'll get added yet, but suffices to say...soon.

RSS feeds for issues
We're adding secure RSS feeds for certain issues. You'll be able to grab a feed for all issues waiting on you, all issues waiting on them, as well as issues waiting on you or them within a specific project. In addition, you can subscribe to an RSS feed per issue. This will include the entire issue history as separate RSS items as well (status changes, priority level changes, comments, and re-assigments).

Commenting to an issue via email
You'll soon be able to comment back to an issue just via replying to an email. This will make it convenient to quickly postback a reponse to an issue you just received.

Tagging an issue
We're working on a simple way to tag issues with custom labels. It will make it easier to filter issues within a project into more granular buckets (e.g. design, code, copy, etc).

Keep the comments and thoughts coming! And, follow us on Twitter.

Labels: DoneDone

We launched DoneDone about a week and a half ago. Thanks to the many that have signed up, played around, tweeted, blogged, and also gave us some very helpful comments. I wanted to sum up the gist of the responses we've been getting.

Overall, we've gotten some nice compliments on DoneDone's simplicity and general elegance. Some have referenced it as an example of how their issue tracker should be.

"I think this style of user interaction would be [sic] excellent to bring to Redmine, making it more natural for users to push issues back and forth without needing to scroll up/down through heaps of comments to find why they've been assigned the issue."

"Interesting new issue tracker: http://www.getdonedone.com/ ...I wish someone would make a self-hosted app that's this nice."

"Just comparing your homepage to this one (http://www.extraview.com/5_free.html?gclid=CO_RgqbLgpoCFSMSagodpRhJFg) gives me warm fuzzies."

However, let's focus on what people are asking. Here are a few common feature requests:

Self-assigning issues
By far, the most requested feature is allowing you to assign issues to yourself. Currently, DoneDone doesn't allow you to do so. This was a very early product decision on our part. We felt that self-assigning an issue breaks the "finder" vs. "resolver" paradigm and the "you" vs. "them" responsibility concept that is core to DoneDone's issue organization. We also felt that if you really really wanted to self-assign issues, the creative hack would be to add another user using a separate email address you have.

Many of you did just that but don't like the workaround. This is a hot item we'll think through more thouroughly. It would be easy enough to just allow this functionality in as-is, but it would make the current application functionality a bit confusing. For example, there would be little use to having the "Not reproducible" status available for a self-assigned to-do.

We'll take a gander at this one and come up with something thoughtful.

Tagging and labeling issues
Some of you want to be able to tag issues - not available in the current build. Travis from San Diego mentioned an easy workaround, by just using a naming convention in the Title field of an issue and then doing a keyword search against it.

However, we do think there's good value in labeling issues - especially if you're using DoneDone to track issues of various sorts (e.g. design, copy, programming, browser-testing, accessibility, etc.) Expect us to add this in a future release.

Discretionary emailing
Another common request is to have some control of when you're getting emailed. Currently, DoneDone emails you whenever an issue you're on has changed. DoneDone also only emails release build notes to people responsible for resolving an issue. However, what if you just want to add a note or comment to an issue without having to bug the other person? Or, what if you want to add other people to a release build email?

This one falls under the "we knew people would request this at some point" list. It will likely find it's way into a future release shortly.

Stay tuned as we continue to nurture DoneDone into the Best Damn Issue Tracker Period^TM. We take people's requests and our own opinion equally seriously.

Labels: DoneDone

On April 15th, 2009, we successfully launched DoneDone. What say we? DoneDone. It's a web-based issue tracking tool made for real humans finishing real projects.

We built it because we were tired of using tools that made us feel like Excel and a drop-down menu made babies. We built it because there wasn't a tool out there which supports the way development teams and client teams interact in the final stretch of a stressful project. We built it because we were missing a crucial tool to help us finish strong.

We realized the biggest help we could give users was an absence of the 'kitchen sink', so each and every feature was stripped and thoroughly searched before it made it into DoneDone. In the end, DoneDone is a streamlined tool which tells you what you need to do next. It makes an otherwise expansive table of issues seem tame and doable.

The cost of DoneDone also came under close scrutiny. We ended up doing things a bit differently here too. Some tools charge an arm and a leg for features Stephen Hawking might find nebulous. Other tools push tiered-pricing based on buckets of projects.

We decided to make it simple. DoneDone costs $24 a month to run a single, active project. For this price, you get 2 GB of file storage, unlimited team and client members, and all-you-can-eat issues. So what if you need more projects? Well, additional projects cost $5 a month. When you're done with a project, you can archive it and we won't charge you anymore. It's that simple.

If you're a coder, DoneDone has an API to make whoopy with your other favorite tools. If you're into project management, it syncs up with Basecamp to grab all of your team and client contact information.

How we built it? X2O, of course.

So, sign up for a trial. Better yet, sign up for real. We love it, and think you'll find it promotes a healthier finish to your projects, and will probably lower your blood pressure. So, good luck finishing strong!

Labels: DoneDone

This is the final post in a five-part series introducing DoneDone, our simple, straightforward issue tracking tool to finish projects strong. Sign up for a 30-day free trial or paid account at http://www.getdonedone.com.

In today's final introductory post to DoneDone, we introduce release builds.

When we first started using other issue tracking tools, we discovered a recurring problem with how issues worked. There was no easy way to take all the issues we fixed since our last build and release them to our clients for retest in one batch.

In Elementool, we did this by creating a custom issue status called "Internal - ready for retest" to distinguish from "ready for retest." Whenever an issue was fixed by one of us developers, we'd mark it with this "Internal -RFR" status. This meant a bug was fixed but not available for our client to see until our next build.

Each night, Lindsay would create a release build email to the client and change the status of each issue to "ready for retest" by hand. For just a few issues here and there, this wasn't a big deal. But, there were times when a new release of the project had 50 or more issues associated to it. Doing this bit of manual labor was tedious and unrewarding.

Elementool treats issues like so many others - just a bunch of numbers in a bucket. There's no human-friendly meaning to issue statuses. They're just tags. This inspired us to create a very simple process in DoneDone aptly named "release builds."

When you create a new project, you can enable release builds on the project settings page.

By enabling release builds, DoneDone creates a new issue status called "Ready for next release." When someone is done fixing an issue, they mark it "ready for next release" and simply move on to another issue.

Whenever you're ready to post the latest version of your project for your clients to review, an administrator can go to the release builds page and create a new release build.

The release builds page shows you all issues in the "ready for next release" state. By creating a release build, three things happen:

• DoneDone moves all issues in the "ready for next release" state into "ready for retest"
• DoneDone also preps an email (which you can edit) that will be sent out to everyone who's assigned an issue in the release build. They are the ones responsible for confirming whether the issue has or hasn't been resolved.
• Finally, release builds are tracked in the build history. This is a nifty way to keep track of all the release builds for a given project and all the issues that made it in each release build.

What would take maybe a half hour to do by hand is wrapped up in one button push in DoneDone.

Nothing revolutionary. Simple and straightforward. We just haven't seen it thought through in any other issue tracking software. So far, it's become one of the most valuable features of DoneDone.

Sign up for a 30-day trial at www.getdonedone.com.

Labels: DoneDone

This is the fourth in a five-part series of articles introducing DoneDone, our simple, straightforward issue tracking tool to finish projects strong. Sign up for a 30-day free trial or paid account at http://www.getdonedone.com.

So far this week, you've read about DoneDone's real time responsibility approach to issue tracking, seen how issues look and feel, and discovered how you can search for issues. Today, we'll show you ways DoneDone integrates from outside the application itself.

The DoneDone API
For developers, DoneDone provides a standard web service API. An administrator can enable the web service for any DoneDone project and copy the WSDL location from the project settings page. You can use the API to:

• Login as a specific user
• Create a new issue for an existing project (allows you to attach one file)
• Add a comment to an existing issue (allows you to attach one file)
• Get all projects available to a specific user
• Get all people in a project
• Get all available priority levels

If you're actively integrating DoneDone with your own tools through the API, we'd love to hear from you!

Shoot bugs down with Bug Shooting
Bug Shooting is a free desktop screenshot utility that integrates with bug tracking systems including FogBugz, Gemini, Ontime, BugTracker.NET and Mantis Bug Tracker. We're excited (and grateful) to announce that you'll be able to upload screenshots as bugs directly into DoneDone in their next release (version 1.9).


Import your Basecamp companies and projects
Like many small businesses, we use Basecamp as our primary project collaboration tool. While it has been invaluable in keeping us organized during the definition and development stages of our projects, it doesn't suit us particularly well when we're in the final phases of a project. That's when we've historically turned to a traditional bug tracking tool (and nowadays, DoneDone) to wrap up the final phase of a project.


We have a hunch many companies are in the same boat. That's why DoneDone integrates directly with Basecamp. It allows you to import companies and people within those companies straight into DoneDone. That means moving from Basecamp (for the vast majority of a project's lifecycle) to DoneDone (for the final push of bug fixes) is a small and natural step.

In the companies/people page, click "Add new company" followed by the "Import from Basecamp" link. Then, login with your Basecamp credentials and choose the companies you want to import. DoneDone will automatically import all companies and people inside those companies. You can then go to DoneDone's companies/people page to add, edit, or delete people, as well as, to send out login information to each imported person.

As we continue to improve DoneDone, we'll likely add some more integration points. Got a suggestion for us? Email us at feedback [at] getdonedone [dot] com.

On Friday, we'll discuss one of DoneDone's simplest but most useful features, release builds. Release builds let you move batches of issues into retest mode, and send emails out to everyone responsible for testing those issues.

Labels: DoneDone

This is the third in a five-part series of articles introducing DoneDone, our simple, straightforward issue tracking tool to finish projects strong. Sign up to get a launch alert and view a quick features list at http://www.getdonedone.com. We'll be launching DoneDone within the next few days...

Today, let's talk about search. DoneDone gives you smart options for searching issues. The search feature lives in the bar just under the project name on each project's home page.


Search by a word or phrase
Type in a word or phrase, hit go, and we'll list all the issues containing those words in the title or description.

Search by issue number
We'll take you right to the issue.

Search someone else's (or an entire company's) issues
When you search someone else's issues, you can look at all the issues that they are working on. Just like your own issues, we break it down by what really matters. In the example below, we're looking at John Smith's issues in the "Internal website redesign" project.


You can see what issues are waiting on John and what issues he's waiting on from others. Also, you can see active and closed issues assigned by, or assigned to, John . Once again, DoneDone keeps the focus on people. We think that organizing issues by who's responsible for the next step is a more efficient way to digest issues during the QA process.

Similarly, you can search on an entire company's issues. Here, we just list active and closed issues.


In most cases, these options should suffice. But, for cases where you need something more particular, you can create a custom search.

Custom searches
Clicking the "Create a custom search" link in the search bar will reveal the custom search panel. In a custom search, you can search issues in a number of ways.


Want to find all high priority issues assigned to you in the last two days? Or, all issues that currently cannot be reproduced? The custom search form lets you filter issues by the following parameters - created by, assigned to, priority levels, issues statuses, creation date, and update date.

Custom searches can also be saved. By providing a name to the custom search, DoneDone will remember your search parameters next time. So, you can just go back to the project home page and select your saved custom search from the "Saved searches" dropdown list.

This is particularly useful if you have common searches you repeat over and over again. At WAM, we're frequently asked to run reports on issues from our clients. Now, anyone using DoneDone can run and rerun issue reports themselves.

Tomorrow, we'll take a look at other ways to integrate with DoneDone, from our API to Basecamp to Bugshooting.com.

Labels: DoneDone

This is the second in a five-part series of articles introducing DoneDone, our simple, straightforward issue tracking tool to finish projects strong. Sign up to get a launch alert and view a quick features list at http://www.getdonedone.com. We'll be launching DoneDone within the next few days...

Most issue trackers don't get the human-side to issue tracking. But, resolving issues is a very human thing. In fact, it's usually something we're not all that good at doing. We're stressed, tired, and on edge toward the end of any project. Seeing pages and pages of this doesn't help:


Nothing about a normal issue tracking page tells you clearly what's going on. Sure, you can look at a status box, and read through comments. But, a good issue tracker makes these things obvious. A poor issue tracking UI is just one more piece of low-grade stress your team doesn't need in the homestretch.

Here's what a typical DoneDone issue page looks like in full (click on the image for the life-size version):

It's clear what has to happen next
In this issue, Michelle, the person who assigned an issue, sees that it is ready for retest. It's bright, obvious, and clear. She simply has to verify the fix and then either click "Not fixed" or "Fixed" in the bright yellow box to the right.

It's easy to see what happened before
Michelle scrolls to the bottom of this issue page and sees 7 items in the history. The four highlighted items are new to her since she last visited the issue. This way, she gets a quick understanding of what's happened since she last paid attention to the issue. Most issue trackers don't tell you what's new or updated. When you're working on dozens of issues at a time, it's hard to remember. DoneDone helps you out.

Knowing context means you waste less time thinking
Issues aren't static. They change over time. Context makes a huge difference. Here's a quick example:



In this case, John assigned an issue to Michelle regarding some font issues on the homepage. In the first image, Michelle poses a question to John. In the second image, John is looking at the newly updated issue. The question isn't just buried in the history, it's brought right to his attention for him to answer.

Confronting an issue page littered with dropdowns and textboxes, or looking at a history that doesn't tell you what's new, makes the not-so-fun practice of issue fixing even less fun. DoneDone wants to take all the extra bits of thinking out of the equation. You focus on assigning, resolving, and testing issues, and nothing more.

Tomorrow, we'll take a look at how DoneDone handles issue searching. Simple to use, but robust enough to suit any level of searching.

Labels: DoneDone

This is the first in a five-part series of articles introducing DoneDone, our simple, straightforward issue tracking tool to finish projects strong. Sign up to get a launch alert and view a quick features list at http://www.getdonedone.com. We'll be launching DoneDone within the next few days...

All client projects should end on time.

But, this rarely ever happens. Whether it's a piece of software, a book, or a building, any project that involves a group of people with different responsibilities usually ends like a bull rush. A stampede of odds, ends, and whole parts not yet implemented. The last phase of a project is a cocktail of unanticipated obstacles and miscommunication, with a pinch of chaos.

DoneDone is all about real-time responsibility
You can blame it on the client, yourselves, or the tools you use. In the end, we've found that the key to finishing a project is real-time responsibility. Who's responsible for fixing a bug right now, responding to a question right now, moving a batch of resolved issues to those that need to test it right now, or testing that something is actually fixed right now? When even one person lets up, projects start slipping behind schedule..

DoneDone is the antidote - a different kind of issue tracking tool focused primarily on real-time responsibility, not just issues. It's a better way to get through the final phase of a project. DoneDone cares about what needs to be done next.

The DoneDone dashboard
What do we mean by real-time responsibility? Here's the DoneDone dashboard. It's the first thing you see when you login to DoneDone.


Instead of a laundry list of issues, you see only what's really important to you. Your active issues. Your closed issues. The blue column tells you how many issues are waiting on you.

• You need to fix issue #8, you need to retest #15
• Mike's asking you to clarify something in #18
• Anthony can't reproduce issue #22.

As long as you get the "issues waiting on you" column down to zero, issues keep moving to the right person.

The "issues waiting on them" column tells you how many issues you're waiting on.

• Tom needs to work on an issue you created
• You're awaiting Mustafa's response to a question on issue #11
• You need Lindsay to retest issue #34
  

Issues get done faster because DoneDone helps keep them moving.

Unlike most issue trackers, we also let you know what's new or updated on the dashboard, project homepage and issue pages, so you're always caught up with what's changed since the last time you've visited DoneDone. You no longer have to wonder, have I already seen this update before?


The project home page
When you go to a project, you see just what you need to get done. We show you your active issues, issues that are waiting on you, issues that you're waiting on, and your closed issues.


Here, you can easily see what issues are new and what issues have been updated since you've last visited.

DoneDone vs. the rest
Like other popular issue tracking tools (say, Bugzilla, Elementool, or FogBugz), DoneDone lets you assign priority and status, discuss issues, re-assign them to someone else, and attach supporting documents. But, most issue tracking tools stop there. Most just feel like a repository of infinitely sortable issues in a database. How you decide to organize and digest them is left up to you.

That's a bad way to keep people motivated. QA and testing is often tedious and burdensome as it is necessary. Your team has been working on the same project for months. People are tired and all the big decisions have been made. Now, it's all about finishing. And, it's often the hardest thing to do.

Tomorrow: We take a look at what a DoneDone issue looks like. From creation to completion, you'll see how our approach works better than the rest.

Labels: DoneDone

Beginning Monday, I'll be starting a 5-day blog post series introducing DoneDone, our simpler, smarter issue tracking tool (and it's all web-based). I've written about it a few times in the past few months, but now we're finally ready to release. Here's what we'll cover:

• Monday: Real-time responsibility with DoneDone
• Tuesday: How we handle issues
• Wednesday: Searching issues with DoneDone
• Thursday: Integrating with DoneDone
• Friday: Release builds

The 5-day post series will give you a pretty good overview of our first live WAM product.

So what is it?
DoneDone is a simple, smart issue tracking tool to finish projects strong. We built it because the way we've tracked bugs for projects with clients and internal projects hasn't gone as smoothly as we think it can. Other bug/issue trackers feel like glorified Excel spreadsheets. We wanted to build something that focused on the people and process, not the issues themselves.

Who's it for?
Small companies, businesses, or individuals who use a bug or issue tracker for internal or client projects. If you've used tools like FogBugz, Elementool, Bugzilla, Mantis, or just plain old Excel to track "things that need fixing" you owe it to yourself to try ours.

When's it coming out?
We are tentatively scheduled to release the application for sale on Wednesday April 15th, pending some final testing next week. We'll announce the official date early next week.

How much is it?
We're launching with a free trial version and a paid version. The free trial will give you 30 days to play around with DoneDone. You can create one project to track issues against. The paid version costs $24 per month for the first project, and then $19$5 per month for each additional project. We let you archive projects so you aren't paying for ones you're done with.

The paid version also gives you plenty of storage for file attachments (2 GB) and access to our web service API.

Stay tuned...

Labels: DoneDone