Ryan Scherf is currently developing the web application SixCentral to assist freelance designers in their proposal writing process. Below he details how Getting Real has helped his team.
Let me start by saying that Getting Real by 37signals has drastically influenced how we chose to build SixCentral. This is a book I would recommend to every single person or shop trying to start their own business by creating a new web app.
In this post I’ll outline how the SixCentral team was able to take ideas and advice from Getting Real (GR), and apply them to our situations with our app.
What we did well
Create something you would use
GR touches on the foundation of any good web app. Web apps are built to make things easier, and if they can make things easier on you, thats even more of a plus. Luckily for me, I was a freelance designer with a problem. I didn’t have one simple way to manage all of my bids and proposals in an efficient manner. Sure, there are dozens of invoicing apps that probably could have done the trick with estimates and other features, but I wanted something specific. I wanted a structure that was easy to use, but most important repeatable. I was getting tired of copy/pasting from a Draft e-mail sitting in my Gmail inbox. Out came the idea that we could create a repeatable process (importing draft proposals), that could then be customized for any client (via client url’s, passwords, etc) and send to prospects. It was essentially that simple, and something I knew other freelancers desperately wanted but failed to find in other apps.
Less documentation, only features that matter
We began by trying to write down every single feature we could possibly imagine that we thought would be cool in the app. As you can imagine, this was a pretty healthy list. Fortunately for me, the lead developer (Wess Cope) was a huge proponent of what he called ‘feature creep’. Feature creep in a roundabout way is the same as implementing features that just don’t matter. We had great ideas about including an invoicing system that was second to none, an advertising platform for services relating to freelancers and pretty much everything else under the sun. One thing to note here is that this is as far as we went with our documentation — one list. All other requirements were done on the fly, either by me mocking them up in the UI or communication via IM at all hours of the night.
We then went wild on our list; starting to cut out features that were either:
- Too time consuming to implement for a first launch without knowing any true value of the feature
- Just don’t matter
We ended up with a pretty core set of features we felt were absolute essentials for our initial launch. Sure, we could have added in a ton more fluff, but we didn’t have the time. We wanted to release quickly with the best possible product we could build. Those features are:
- Proposals (create/view/edit/send/import/comment)
- Invoices (create/view/edit/send/comment)
- Clients (create/view/edit/note/profile)
- Calendar (create/edit)
- Client portal (view proposal & invoice/comment/accept, postpone or deny)
Let others find workarounds
We knew that every freelancers process wasn’t the same as mine. Perhaps some people wrote their own app to fill in details on a proposal their own way. We were fine with that. We knew that people would use SixCentral for their own needs, whether it was our intended way or not.
A perfect example of letting people work around our system is the Proposals themselves. A Proposal is just a set of multi-line textboxes that support some basic HTML. We broke the Proposals into categories we felt made sense, as well as added one last area: Other. The Other area was our way for accounting for the unknown. Perhaps person A would use this for a link to their NDA. Person B may use it for a link to their own website. It didn’t matter to us — it’s just text in our database, but it provided a great workaround for people that needed just a little extra, less-specific space on each Proposal.
Our demographic was smart enough to use our app in ways we probably didn’t imagine. Ironically enough, we’ve had realtors and plumbers e-mail us about using our app for their own business.
Promote early, offer exclusive looks & release often
From idea to first beta, we spent 1 month designing and developing. This included a blog, a landing page and an app. After 1 month, our beta users could successfully register, create new clients and create new proposals for clients. We immediately began receiving feedback to our GetSatisfaction page. Since at this time it was only Wess and I, we didn’t have time to QA our product. Instead we relied on the early adoption beta testers to help us through this — and they surely did. We fined tuned all of our bugs and requests, and quickly released a second beta which included our ‘client view’, so a user could create a proposal and send it to a client.
We also had a teaser landing page, collecting e-mail addresses the very same night we had the idea. We submitted it to some design galleries (which were conveniently in our niche market), and quickly had hundreds of subscribers awaiting the launch and requesting to help with our betas.
We had one last beta release about a month ago, and are now working on releasing the full product sometime in August.
Self Funded
Fortunately for us, we never had the opportunity for any type of funding. We chose to build the app in our spare time, outside of our day jobs and family life. It was always been a struggle in terms of communication and deadlines, but we’ve pushed through.
Where we went wrong
We missed our own deadlines
Things got in the way, and we had to move some deadlines. We probably didn’t launch as quickly as we would have liked. We lost the enthusiasm as the day jobs started to become overbearing. Ultimately we pushed through, but we could have been more proactive in hitting our marks.
Too many features
We probably have too many features that may not matter to everyone. We added invoicing to our app, but what are the chances that someone will change from InvoiceMachine, FreshBooks or Blinksale to use our solution? Probably not very good. At the time, we felt it was important to at least offer a bare bones invoicing platform in the event we picked up some users that perhaps did EVERYTHING by hand before SixCentral.
Conclusion
After rereading this post, I’ve realized now that our app launch was very successful. Not just because of the number of users, but because we actually did it. We did most things right, with a few things wrong — but we still made it to the finish line. We have a product that we are proud of, and a team we are all thankful for. In the end we made great friends that have similar interests and want to build great apps. For that, we cannot say enough.
If you have questions, comments or thoughts, please feel free to e-mail us at: info@sixcentral.com.
