Articles about business
When you run a SaaS business sending out invoices is your lifeblood. Hopefully, you're generating a ton of invoices and sending them off to your customers.
Here are a few best practices to consider after automatically charging your customers.
Let's assume I write software for a living.
Let's assume I built something and the total cost of development is a nice round number like $10.000.
Let's assume I expect to sell a certain number of copies, say 1.000.
Let's assume I like to turn a profit (I do) and not give away my work (I don't). How much should I charge?
$1? Don't be ridiculous.
$10? Assuming every copy is sold that'd put me at break even. But at $0 net I might as well not have built anything. And if I don't sell 1.000 copies, I'd have lost money.
$20? Now we're talking. I'd be looking at recouping my costs and making a decent profit - I might even be able to pay for food and housing for a few months.
$100? If 200 customers find my something worth that much, why not?
Now, let's assume the number of copies with certainty cannot exceed 1.000 for whatever reason.
How much would you charge?
The following are quotes from an actual email conversation with a potential customer.
I’m no fan of bullshit NDAs, so I’m just sending this and I trust you that this’ll not end up on Twitter or anything
I know quality has its price. […] I don’t like the wheeling and dealing either. If you say it’s your rate, it’s your rate
We would certainly not be against contributing back to the [open source] community
I must close this deal.
There are basically two kinds of deadlines: Real, and Arbitrary.
Real deadlines are those necessitated by some external, unchangeable event. For example legislation, the company running out of money, the CEO having to get up in front of the world press and announce the product, or a marketing campaign kicking off.
When building a new software project, you should focus on building your core functionality – usually the magic sauce that makes your company money.
This might seem obvious, but many people don’t realize just how much extra work is needed to support the money making part. Not only are there many supporting features, it can also be hard distinguishing them from your core features; after all, they are all needed to run the business, so they must be important, right?
Unless you have unlimited funds, your success is going to be dependent on your ability to figure out the correct set of core features to work on.
Running my own web development shop unfortunately means I have to do contract negotiation and dealing with other legal mumbo jumbo. It is not an aspect I particularly enjoy, especially not when the potential customer tries to restrain my business by sneaking a non-compete clause into the contract.
Agreeing to a non-compete limits your ability to do business in the future. If you do this enough, you will run out of customers to work for and that is – not surprisingly – bad for business. As a business owner, you need to fight this.
Rails Rumble is an annual, 48 hour web application programming competion. This year around 300 teams attempted to build and launch a web application over the course of a weekend, 180 succeeded.
Participating in the Rails Rumble is a lot like being in a startup, just a heck of a lot more focused. A small group of people with nothing but an idea, passion, and a tight deadline. As such. there are some lessons that apply equally well to Rails Rumble as to launching a new startup.
All software projects trend towards The Big Rewrite.
Last week I did something I very rarely do. I – together with visual designers, barq – replied to a Request For Proposal. The experience confirmed my suspicion that RFPs are indeed a broken concept.
One of the many things I try to make my customers realize, is that their web application is never done.
There is always something that can be made easier to use, pages that can be made to load faster, new features that can be implemented, existing features that can be made more powerful, or landing pages that can be optimized.
Being self-employed is hard. Having no one around to tell you what to do brings up a slew of problems, one is that of focus.
Should I start another personal project, learn a new technology, create a (well, another) small game, start working on a long overdue redesign of mentalized.net, build an iApp (what is the common denominator for iPod Touch, iPhone, and iPad apps?), write a blog post, something else?
And that list doesn’t even include the important stuff like relax in front of the X-Box, watch a movie, take a walk through the forest with the wife, play with the dog, or make my son laugh.
How does one stay focused in that environment?
When I founded Substance Lab I knew I wanted to build a virtual business – or at least as much as it could be. Why should petty details like physical locations decide whether I can help my clients?
From the get go, I chose primarily web applications to run my business on. Also, it kind of makes sense because that’s what I am building, and there is no better way to learn about good and bad web applications than using them yourself.
Let me give you a rundown of the most important ones.
It’s one of the best decisions I’ve ever made.
Being directly responsible for my own income has been fun, empowering, fulfilling, and pretty damn scary. I’ve met lots of great people, worked with great customers on great projects, and I’ve learned a lot of lessons in the process. Allow me to share a few of those lessons with you.
Your network is important
I am a geek. I am not particularly outgoing. Small talk is not a forté of mine.
However, as a freelancer, entrepreneur, or anyone running a business you cannot isolate yourself in a dark basement producing high quality work. You need to get out of your chair and meet people – partly in order to stay sane and get outside influences, but definitely also because your network is very important to your business.
I have gotten the majority of my customers through my network. If you provide a great service, your previous customers will happily recommend you and your coworkers will happily refer clients you. If you’re a great person, your friends are going to talk about you.
Leverage your network, and don’t forget to make yourself available for them as well.
Running a business will consume you
One of the things I have been most surprised by, is how much I think about the company.
There are always a ton of things to think about; processes that could be improved, ideas that might be worth pursuing, people to get in touch with.
Whenever I have some downtime; doing the dishes, walking the dog, watching television or in some other way allow my mind to wander, it tends to wander towards Substance Lab.
You won’t bill out as many hours as you think
Many other people have written about this point in length, but it is important enough to bear repeating.
If you plan on working reasonable hours – and you should – you cannot expect to work 8 billable hours per day. There are so many other tasks that you need to take care of, that a part of running the business. Admin, taxes, sales, marketing – Jon Hicks have a longer list-.
I have, on rare occasions been able to work 6-7 billable hours in a day, but more realistically, I count on around 3-4 billable hours on any given day.
Scheduling is really hard
Things will take longer than you think. Period. Couple that with the fact that you probably won’t be able to work as many hours as you figure, and you have a scheduling problem on your hands.
You want to minimize the amount of time without client work. But at the same time you need to leave buffers in place for when your estimates are flat out wrong or when something goes wrong and needs to be dealt with.
I wish I had any words of wisdom to dish out that would instantly transform you – well, myself – into a scheduling demi-god. Unfortunately, I don’t. For now, I am relying on optimism and a lot of running really fast when things get tight – hardly optimal.
I’ve shown you mine…
That’s just a few of the lessons I’ve learned over the last years of freelancing. If you do any freelancing or run your own business, what have you learned? What would you tell someone who’s thinking about starting out on their own?
I pulled the plug on a project today. The project was the first Rails project I ever built, and my first, feeble attempt at getting some of all those free money I’ve heard is floating around the internet.
4 years ago, when I was still thinking PHP was a great language, I needed a real project to use for my experiments into Rails. At the time, I was getting into playing World of Warcraft along with a bunch of friends, and we needed a website where we could discuss tactics, organize events, and all the other small tidbits that go into running a guild.
I figured I could use Rails for that website, and hey, I might even be able to make a little money on the side by letting other guilds use the same application on a pay-per-month basis. Step 1: Build it – Step 2: ? – Step 3: Profit! As it turns out, step 2 is actually pretty important and harder than I thought.
Things I did wrong
Over the last course of the project, I’m sure I’ve made a lot of mistake. Following are a few of them, the ones, I think are most important. Writing them out here, shaming myself publicly, will hopefully result in me not forgetting the lessons learned.
Perhaps someone else might even learn from my mistakes.
I was not passionate enough
Probably the number one reason for the failure of Guildspace, was the fact that I did not take the project seriously enough. All the other problems can be traced back to this.
I built the application for myself and some friends, and the business part was just a stray idea. As long as we used the application, I was motivated to improve it. Consequently, when we stopped using the application, I lost the motivation to build the application.
Certainly, if the application had customers and was generating revenue at that point, I might have been motivated enough to keep it running, but the reality was different. Which isn’t surprising, because no one knew about Guildspace.
I didn’t tell anyone
I launched Guildspace with no real plan for how to market it. I invited a few friends and members of my family who used the application and were reasonably pleased with it, but other than that, I never really told anyone about it.
To this day, I am surprised by that fact. I have a weblog with thousands of visitors every month, yet I’d be very surprised if any of the readers of this blog knew about Guildspace. To be fair, I’ve never claimed to know the first thing about marketing. Yet, I could easily have done better than what I did.
I wasn’t prepared to invest
My lackluster attitude towards the project also resulted in my not wanting to invest any money in it. Sure, I could pay for a few domains, but that was pretty much my upper limit when it came to hosting. You know what? If you want to turn a project idea into a profitable business you need to invest money in proper infrastructure. And no, the cheapest hosting plan you can find will not cut it.
Hosting wasn’t the only piece of infrastructure I skimped on. I didn’t want to spend money on proper payment processing. I figured, as soon as the customers start flowing in and I actually have some payments to process, I can just use PayPal. They only charge a transaction fee, so if I don’t make money, I don’t pay them anything. Big mistake!
In order for PayPal subscription payments to work, the customer needs to create an account on PayPal – or if they already have one, log in there. This totally messed up the signup process, but I was too much of a scrooge to care. Not only would a potential customer have to sign up for Guildspace, she’d also have to sign up on a seemingly unrelated website.
Not surprisingly, the majority of new signups never got past the PayPal step.
The net result of all of the above is that Guildspace is no more. The life-support-system keeping it alive has been turned off. I’ve had fun building the application and I learned a lot in the process.
Rest in peace, Guildspace, we hardly knew you.
Whenever I launch a Terminal window, it starts up in a very important folder on my harddrive; my Projects folder. This is where I store the projects I work on – both for clients, but also internal projects and experiments and whatnot.
The Projects folder contains a bunch of other folders, one for each client. Each of those folders contain a folder for each project I am working on for that client. This keeps everything grouped nicely together in my eyes.
And then my neat structure breaks down. The only fairly constant element inside each project is a folder where the actual code of the project is stored. This is usually a clone of the Git repository named, but a projects have Subversion checkouts inside them.
Outside of that, the folder for a single project can contain any number of different folders, usually for design ideas, requirements documents, specs, prototypes, and all the other bit and pieces that exist around the process of building a project.
In the Projects folder is also an Archived folder where I put zipfiles of the projects I no longer work on. The archive folder follows the same structure as the Projects folder, with a folder for each client, containing the zipped projects I’ve built for them.
Contracts and documents
I currently keep my contracts and proposals and documents like that in a separate structure, keeping everything under Projects focused on actually producing the project.
I’ve showed you mine…
I’m kind of curious as to how you organize your projects. Are there any applications I should be using, any important metadata I’m missing out on, or any other tricks you employ?
I have been moonlighting as a freelance webdeveloper for the last couple of years. The first year, I was using my spare evenings and weekends until I began having trouble finding enough time to dedicate to new projects.
Apple, please make it easier for us to consume Steve…
Why is there not a single podcast I can subscribe to, so the HD versions of the most recent Apple keynote, iPhone SDK announcement, or any other reality-distortion-field-spreading event automagically appears on my media center Mac, iPod or iPhone?
As it is now, I have to wait for the video to appear on the website, then open iTunes, then find the podcast, then fetch the single episode, and then wait for that to download. And finally I can view it on my TV. If they instead provided a proper podcast, the iPhone SDK presentation would’ve been waiting for me when I got up this morning.
Apple has probably the biggest podcast aggregator in the world with the iTunes Store. They have near-ultimate dominans on the market for portable audio and/or video players. They have one of the most loyal and fanatic fanbases in the world. They provide high quality videos of their special events and the fanbase is slurping it up. Their marketing machine is highly effective at creating buzz.
They already have all the pieces of the puzzle, they just need to put it together.
They could even provide a podcast of their ads and people would subscribe. It’s free advertising directly to the computer, living room, or pockets of interested customers.
“So you want to link to our free, advertisting supported website? Sure, that’ll be 4500 DKK + VAT (around 979 USD)”
This might sound absurd to you, but it’s the reality this blogger (in danish) faced when he linked to danish mapping service, Krak.
Read that again, then try to grasp the fact that a company like Krak, whose website is plastered with ads, willingly says no to free traffic and Google juice.
Now, the case of Krak vs. Kennel Kaarup (in danish) from above have been resolved with Krak backtracking and issuing a formal apology (“Oops, we figured you were a business entity”), however it’s probably too late by now.
It sure seems to me, that Krak doesn’t want the traffic from you or your website visitors. I am sure both Google Maps and -mashup, Find Vej, does though, so do link to those excellent map services if you wan’t to show people where you live.
This is a followup to my previous rant about the state of accepting online subscriptions.
A few things happened after my post. Most importantly the client met with a focus group of potential users, and – among other things – talked pricing with them. Every single one stated they’d much rather prefer paying a one-off yearly fee instead of automated monthly subscriptions.
Payment gateways, merchant accounts, transaction fees, statements, grraaaah, it’s driving me bonkers.
Here’s the deal: I have a client wanting to sell subscriptions for his web application. Nothing fancy, everyone’s doing it. It should be easy finding a payment gateway supporting that, right? I imagine it is once you manage to wrap your brain around the confusion that is payment gateways and merchant accounts.
It’s been pretty quiet around these parts lately – if you ignore the posts about Copenhagen.rb meetings at least. That’s primarily because I am having tons of fun at work, which for some reason doesn’t leave me much time for blogging. Not that I would ever think of blogging at work, no siree…
Anyways, here are some tidbits about what’s be going around my life recently:
- The BiQ rewrite is going really well, and I am thoroughly enjoying this.
- Copenhagen Ruby Brigade has taken off and the two meetings so far have been visited by 20-25 Ruby heads. I’m really enjoying these meetings and the more social side of software.
- My girlfriend started blogging – primarily for a school project, but it will be interesting to see if she keeps blogging.
- Substance Lab is busy with client work.
- The puppy is growing bigger – she’s almost a real dog now.
I am now well over a week into putting BiQ on Rails, and I’ve been having so much fun. The fact that I actually getting paid for writing code that’s pretty and well tested means so much to the enjoyment of my work.
Thursday marked a major step on the path to exploring Rails as an alternative for BiQ. As I’ve mentioned earlier I’ve been looking for someone to come and present Rails for us. We found Scott Raymond of Blinksale and IconBuffet fame and spent all of Thursday picking his brain.
In Pricing a Project Brian Fling talks in great detail about how Blue Flavor prices their projects (duh). It’s a great article, and I find their process strikingly similar to what I do in Substance Lab.
At a recent project, the client approached me with a set amount of money and said they’d pay me all of them to implement a specific feature. I responded that I would much rather bill them per hour actually spent. They agreed, setting the proposed amount as a max ceiling in the contract. In the end the feature was implemented for around half of what they proposed, making for one pleased customer.
Certainly, I could have made a lot more by accepting the initial proposed amount of money, but it would have felt like cheating. I don’t want to get paid for work I don’t do, and I guarantee you no client wants to pay for it.
I find billing by the hour meets both ends; protecting the client from paying for more than they get, and the contractor from doing work without getting paid.
I’ve been eyeballing MacZOT! before. Basically they offer you handpicked Mac software for greatly reduced prices, and I learned about them when they offered a “MysteryZOT” – you buy a package of software, but you don’t know what you get. Funky stuff.
They are currently offering SubEthaEdit from CodingMonkeys at a $6 discount, but not only that, for each approved blog entry writing about this, they will lower the price by $0.05. If the collective blogosphere manages to lower the price to $0, MacZOT and CodingMonkeys will simply give out SubEthaEdit registration keys for free to all who participated.
In other words, MacZOT and TheCodingMonkeys will award $105,000 in Mac software. That’s viral marketing with an edge.
Read more or buy SubEthaEdit over at BLOGZOT 2.0 on MacZOT.com.
Remembering our pleasant experience from last year we actually went to your site first when trying to book our vacation for the summer. And we had bought from you, if it hadn’t been for the fact that your booking system kept changing our room preference to a different – and more expensive – choice.
Okay, I’m a developer, I know bugs can occur, so you got the benefit of a doubt and a kind email detailing what we did and what error we got. The kind of email that I’d like to receive when bugs occur.
At the day job I’m the sole developer and maintainer of a legacy ASP/VBScript system. Yes, ASP/VBScript. No, not .NET. And yes, it’s driving me insane. The code contains around 42000 lines of VBSCript drivel and 30000 lines of supporting Python code.
The other day I told my boss that I thought we should really, really consider rewriting the application. The existing one is getting cumbersome, hard to maintain, and let’s face it; it’s sucking my soul dry. My suggestion for a new platform is, for a lot of reasons, Ruby on Rails.
My boss was, not unexpectedly, hesitant to say “Sure Jakob, we’ll halt development while you use the next 6 months to rewrite what we already have”. However he was openminded enough to have me try and persuade one of the owners of the company who is a (or at least used to be) techie. Today I met with that owner, prepared to answers question ranging from “but does it scale” over “but what about the performance” to “but how will we ever be able to hire new developers”. It went pretty well.
The bottom line is that I am now looking for an outsider to champion our rewrite. Basically some expert with multiple, deployed Ruby on Rails applicaitons under their belt, who we can fly into Copenhagen, hold a one day seminar/discussion and tell me, my boss, and the owner, why this rewrite is a good idea, what issues we need to be wary of, and perhaps even guide us in a direction that’ll lead to eternal Rails bliss.
I’ve finally managed to pry at least a single specific requirement from the owner: Whoever we get in here to persuade us, must have deployed real, live, revenue-creating production sites in both PHP and Rails. We’re apparently interested in hearing about the differences and benefits of those two approaches.
If you’re up for this, do get in touch with at email@example.com or firstname.lastname@example.org.
I know coming up with names is terribly hard – especially if you want a domain name that goes with it. But c’mon, the numbers thing was cute when only a few had it, now it’s just overdone. The old timers include 9 Rules, 37signals, 43 Things", and now we get 30 Boxes from 83 degrees, gah!
At least 23 embraced the consequence and just called themselves a number and nothing else.