You are here: Home Articles Being small and beautiful
OpenID Log in


Being small and beautiful

by Martin Aspeli last modified Dec 26, 2009 10:45 AM

Some thoughts on what makes a small (software) business successful

In most countries, small businesses are the backbone of economic growth and employment. This is especially true in technology, where small businesses and startups also often drive innovation and quality improvements in their field.

I've had the opportunity to work for a couple of small (5-20 people) software development companies, as well as for some really big companies. More importantly, I've been in a position to help medium and large clients procure services from smaller vendors, advising on such things as the risk of relying on a smaller partner and the potential benefits of a closer working relationship and specialised expertise.

Sometimes, this type of partnership works very well, but it can also be pretty frustrating for all parties involved: the client, the vendor, and the hapless business consultant in the middle trying to smoothen out the process. That's usually down to details: differences in expectations, poorly written contracts, communication problems, or differences in working styles.

It's not always easy to give feedback individually, but here are some collected thoughts. These are not directed at anyone in particular. In fact, I think I've been lucky with the small businesses I've work with. Still, I'm sure many of us would recognise some of these challenges from projects past.

Know your size

I'd bet that most small software businesses work primarily for clients that are larger than themselves, be that in the private or public sector. This has implications for the relationship between client and vendor. In particular, the client is exposed to more risk than you are (or at least they'll think that they are), because if you go belly-up, the client is unlikely to get their money back. This is not a bad thing, so long as both sides are aware of it. If the old adage that "the client is always right" holds true, a corollary may be that "a bigger client is always more important than you are".

Of course, that doesn't mean the client should be given free rein to boss you around. If you are honest about your size, the client needs to respect that. If they start asking for the impossible, such as exclusive access to people who are also needed on other projects, sit them down and talk to them about your business and why things are they way they are. If they can't hold up their end of the bargain, it's time to look for new clients.

The size mis-match sometimes becomes acute when a small business tries to sound bigger than they are. Nothing makes a client think "amateurs" like hollow attempts at grandeur or obfuscation. Personal favourites include:

  • Every employee has a CxO title. You're the CEO, your wife's the CFO and the guy you just hired is the CTO. A CEO (at least in Europe and Australia) is associated with someone who leads a large team and makes executive decisions. Certainly not someone who does day-to-day grunt work (like programming or, worse yet, support). If, on the other hand, you call yourself "Partner", you're probably on safer ground.
  • Some employees have more than one CxO title. We're two people who run a company. You're CEO and CTO, and I'm CFO and COO. Right.
  • Obviously vague statements about size, turnover, etc. The worst case scenario here is a one-man company that pretends to have employees. (There's nothing wrong with being a one-man company. It just means that as far as your client is concerned, you're a contractor. That's likely to make your life a lot easier anyway, since the client will probably handle some of the administrative overhead for you.) If you're a bigger company, be honest and unapologetic about your size. The client has made a conscious choice to go with a smaller vendor. They're not going to suddenly run away because you're 8 people instead of 10.

Be clear about what you do

Some people never say "no". The problem is if you tell your clients you can do everything, they expect you to be good at everything, too. And one big failure is going to loom larger in clients' memories than ten success stories. Tough luck. If you're not very good at requirements management, or web design, or PostgreSQL, don't tell them you can do it. Find a way to work with others who are good at it instead.

This also has to do with confidence in front of the client. If you can't explain to a client in a few short sentences what you and your company do best, start working on that right now. As in dating, a show of confidence can go along way towards sealing the deal.

The best focus statements I've seen tend to be:

  • Concise
  • Compelling
  • Focused on customers' business problems, rather than presumptive technology solutions
  • Industry-aware - if you understand a client's industry, you're a lot more likely to speak their language and be able to predict their challenges

Conversely, one of the worst ones I've seen went something like this: "Almost no matter what your problem, we'll find a way to apply Python and Zope to it". I paraphrase. And I forget where I read it. But this implies that you have a mighty hammer, and pity the projects that you may look upon as nails.

Are you a 'product' business or are you a 'service' business?

I submit that this is the kind of thing you need to decide up-front, and be brave enough to stick to it. Companies like IBM will sell you products (e.g. software licenses or hardware) as well as services (consulting, development), but they are huge and they keep those parts of their business quite separate. If you're a small company, you can sell products (i.e. deliver physical products or sell licenses), or you can sell services (i.e. work on projects). You can't do both. Or at least you shouldn't.

Selling things and selling services are quite different activities, that place different demands on a business. If you sell software licenses, clients are going to expect salespeople, professional documentation, rapid security updates, license management and bulk licensing deals, solid support, and continuous improvement to the product. Development requires a substantial up-front investment, as well as ongoing investment in maintenance and updates, marketing and so on.

If you are delivering projects, clients expect you to work on their project full time. As soon as you become successful as a consultant or contractor, you're not going to have time to work on your products. Unless you dedicate staff exclusively to supporting and developing your products, you're going to be caught between the rock of your clients and the hard place of your customers. And few small companies have the luxury of ring-fencing people like that.

Fundamentally, this is the distinction between "business-as-usual" work and "project" work. Mixing the two modes of working is hard enough in a big organisation. For a small business, it normally means working for your clients during the day and working on your products at night. That's not sustainable.

The attraction of being a "product company" is that it promises a stable revenue stream and frees you from the pain of project management and complicated clients. However, most companies struggle to reach sufficient sales quickly enough to make back their initial investment and still pay their staff. Project work at least pays straight away.

If you are working with open source, trying to sell licenses can be even more complicated. Using open source technologies is one of the great equalisers for small companies, who can credibly claim that the risk of going with a smaller vendor is counterbalanced by a community of people and companies familiar with the technology. Unfortunately, there won't be a community around your proprietary product, so you end up undoing one of the good arguments for people to buy your services. And that's before you get into the intricacies of copyright and license terms, made even worse if you ever blur the lines and use a customer project to build a product you then intend to sell to others. (Hint: don't do it.)

Are you a project business or a support business?

This one's related to the previous point, but it's harder to get away from support. If you build a piece of software for a customer, they are going to want support.

You probably can't get away from doing support, but you should decide whether you are going to make most of your money on project fees, or in support contracts, and configure your business accordingly. Clients understand the distinction, and will want to know: are you in it only for new development (in which case they will want strong assurances about continued support and, possibly, supportability by other vendors), or are you after a long-term contract (in which case they'll expect a discount on your rates up-front in return for a longer term contract).

You also need to make sure you dedicate enough resources to support on an ongoing basis. Your current support clients are liable to be your next project clients. That is, unless you bungle that crucial call that comes in just when your team is trying to finish off a project for another client. It can be difficult to balance "old" (and perhaps boring) support work with "new" project work, so make sure you build that into your plans from the beginning, or you'll end up on the nightshift again.


Pricing can be really hard. To set your prices, you need to understand something about what your customers expect, and what your competitors are charging, but both your clients and your competitors have an interest in keeping that information from you. You also need to know when to change your prices, and how to build that into your contracts.

There are some useful rules of thumb, though. First of all, you can charge less as a small company than can a big company. This has little to do with the quality of your work or the depth of your expertise. However, there is an inherent risk premium for the client associated with going with a smaller vendor. If you screw something up, chances are it will sting the client more than it will sting you. At least instinctively, most clients believe that bigger companies are less likely to screw up, and better able to back-fill in case of resource unavailability or skill shortages. To a certain extent, this is true. A big vendor working with a big client has more to lose, and will invest in keeping a relationship going. They will also hopefully have more checks and balances internally, and often more experience on which those checks and balances rest.

Cost is often a reason put forward by those in the client's procurement process wanting to go with a smaller vendor. If your costs come in as high as or higher than a "big" name, those champions will have a harder time explaining why your tender should win.

In a very unscientific estimate, I'd suggest that the best place to be is in the upper third of the price range for your local market. If you're the most expensive vendor, you better be damned good, because as soon as the client has to cut cost, they'll start at the top of the rates card and work their way down. If you're the cheapest bidder, they may question your seriousness. Cost can be a signal of quality, but don't confuse cause and effect: you can't charge more in order to appear like a gold-plated option. You'll be extremely closely scrutinised if you make that claim, and if your claim doesn't hold up, you'll be dropped like a stone.

You also need to be transparent about your pricing. Pricing can be very psychological. Many clients will be unhappy about paying a high day rate for a small vendor, even if the total cost is dwarfed by other projects. It simply feels wrong for the five-person company to charge more than IBM or SAP do for their top consultants. This can quickly turn into a charge that you are out of touch with your market.

You should have a rate card. For standardised services, like support, you can put this on your website. For projects, keep it confidential, but share it with your clients. Your rate card needs to set out a day or hourly rate for each type of resource you have, e.g. senior developer vs. junior developer. Clients also like discounts, so feel free to show them a rate card and then outline a price based on a discount.

No matter what you do, though, for the love all that is good and holy, produce a simple price table that makes it abundantly clear what the client has to pay, and when they have to pay it. If the client has to think (or bring out a spreadsheet) to figure out the total cost, you've lost. If it's not clear what's to be paid up front, and whether there is an annual cost involved for support, you've lost. For example, if you itemise "development" and "annual support", is support included in year 0? Is it payable from when the project begins or ends? What if there are multiple releases? "Creative", unclear pricing is probably the number one way to look unprofessional. You should have a single pricing model and stick to it, not leave it up to each tender to come up with some way of making money.

Finally, a word about pricing in its wider context: you need to measure your recovery. How many hours do your staff work? How many hours do you pay them for? How many hours' worth do you invoice the client for? And how many hours' worth do you actually get paid, on time?

If you don't have these or similar numbers readily to hand, you're not running your business properly. A lot of small companies fail to invoice regularly, or send invoices that contain errors. This is unforgivable and wreaks all sorts of havoc. If you've ever seen anyone try to bend their SAP finance system to accommodate a vendor that does unusual things, you'll know what I mean.

Ask yourself this: could you lower your prices and still make the same money if you actually managed to recover fees for all the hours you spent on a project? If the answer is yes, you should try to do that, because your customers will feel like you're a more predictable partner, you will appear more professional, your staff will feel like their work counts for more, and you are more likely to win work since you now have a cost advantage. Driving this type of efficiency in your own business is hugely important, and requires constant attention and measurement. And proper internal systems for things like time writing and invoicing. Don't skimp on these. And please don't try to build your own, unless you happen to also sell those types of solutions to clients.

Know your customers

Just as important as knowing yourself, is knowing your customers. This is where industry specialisation can help, although I think that often happens more by accident and word-of-mouth marketing than by design. Ideally, you want to walk into the first meeting with a new or prospective client armed with a solid understanding of who they are, and what they do. Do some research:

  • What kind of business are they?
  • What are the biggest challenges facing them right now?
  • Why are they doing this project?
  • Where do you think this project fits into the overall picture?
  • Who are the key stakeholders for your project? Who are your champions and who are your detractors?
  • Who else are going to be involved from the client's side? How can you get to know them?

I've seen many a small business win out over a bigger rival because the client says, "they know us best". A close partnership and good personal relationships are your biggest assets when you're small, especially in the private sector.


Everybody hates writing tenders. They take way too much time, involve a lot of tedious questions, and the outcome is by no means certain. And without fail, they end up keeping you up into the wee hours the night before submission. However, your tender response is the first impression you leave with a new client. Some obvious things that help are:

  • At the end of each project, spend a few hours writing up a credential that you can re-use. This should be half a page, and answer four questions:
    • Who is the client? You need to check that you can use their name. If you can't, generalise, e.g. "A major retail bank".
    • What problem were they facing? Make sure you don't make your client look bad here. 
    • What did your company do?
    • What were the outcomes? Try to quantify if you can, e.g. "10% cost saving".
  • Re-use sections such as "who we are" and "what we do". Find a structure that works and stick to it.
  • Write proper English (or whichever language you work in). Some clients will not even read a tender submitted that is full of grammatical errors, and even those who do read it will not be impressed by the time they score your submission.
  • Get someone else to proof read. Ask them to try to cut the word count down by 20%. Many people will waffle endlessly trying to sound "businesslike". Don't fall for it. Clients like short sentences and straightforward language just as much as you do.
  • Answer the tender. A lot of client just won't read a nonconformant response. If you really want to suggest a better way, some clients will thank you, but play it safe, and submit two tenders (or an appendix) - one that conforms, and one that doesn't.

Standardise your processes

The tender might get you in the door, but you've got to work hard to stay there. In general, I've found that there are two types of clients: those that have a project management office and expects you to work within their process, and those that expect you to get on with the job yourself. In either case, you'll get the blame if something goes wrong.

If the client has a process, learn it. You should ask for proper training, and figure out where to get support if you have questions. The last thing you want is to be remiss in some project management deliverable. The kind of people who call you up on such things are unlikely to be impressed by your programming skills.

If the client doesn't have a process, you need one. My advice would be to pick one that already exists and is well known, rather than trying to invent your own. Get your people certified in it if you can. Scrum is a personal favourite, but the most important thing is to have a process and sticking to it. It's important that your process includes a means of managing requirements throughout the lifecycle of a project, and gives lots of opportunities for interaction with and feedback from the client.

Keep your communication professional

Every time you communicate with your client - by email, letter, phone or in person - you are either building on or taking away from their impression of you. That goes for every member of your team. If you slide into jargon, come across as flippant (rule of thumb: no humour in emails), or simply give the impression that you are out of touch, you're in trouble.

Also be aware that email is the most dangerous form of communication. A lot of problems in my career could've been avoided had I spoken to someone on the phone or in person, rather than by email. One of the biggest lessons I've learned is that open source developers have an entirely different way of reading and writing emails than clients. A lot of people don't take well to long emails. Some people don't feel it's obligatory to respond to emails, but will normally answer the phone and return messages. Businesspeople often don't understand inline quoting, either.

Finally, be professional at every turn. For example:

  • Come to meetings with professional-looking business cards.
  • Use an email signature that includes your company name and phone number.
  • Record a professional voice-mail greeting.
  • Get someone with design experience to create presentation and document templates and use them, every time.
  • Produce formal documents on company letterhead.
  • Show an interest in your client's problems and listen more than you talk. When you do talk, speak with confidence. Point to your experience and aim to illustrate how you can solve their business problems, rather than highlight how good you are in your field of speciality.
  • Dress like your client. If they wear a suit and tie, so do you. If they're more casual, lose the tie and maybe the jacket. If they're media types, dust off the mail bag and grow that goatee.

These are little things, but they can make a big difference in how you are perceived.


One of the great things about my current job is that we almost always insist on working on-site. The one project where we didn't spend much time on-site was also one of the hardest, and that was not an accident. Working on-site lets the client see the work you do. It allows you to meet people spontaneously or as needed to clarify requirements or other aspects of the project. It allows you to socialise and form relationships beyond the purely functional.

Working on-site can be difficult if you're doing development. Things like corporate firewalls often get in the way. And of course, not all clients are just down the road. Try to do it at least part-time anyway, especially in the early phases of the project.

Don't be your own lawyer

Hire a lawyer. Make sure you understand every contract you sign. Make sure any contract you ask the client to sign has been drafted by a lawyer and doesn't contain anything "weird". Weird contracts are a great way to mire a project in delays, and can come back to bite you in ways you'd rather not know about.


I hope this list has been useful. I'm sure you could add many more. Feel free to use the comments to share your own experiences, or tell me that I'm wrong.

Document Actions


Posted by at Dec 27, 2009 07:00 PM
That was a really useful summary. I'd like to have the "client version" as well, and print them on facing pages to hand to clients: "here is how we'd like to do business."

Flip Side

Posted by at Dec 28, 2009 12:38 PM
I mostly agree with everything you've covered. It may also be worth mentioning though that there are risks on the other side. Two that I have personally seen come right to mind:

First, unfortunately there are some larger (even huge) companies that think it's acceptable to delay the paying of final invoices for a *long* time. I've seen a couple cases where final payments take over half a year. I suspect these same companies do not treat other larger companies the same way.

Second, while there are many benefits to working on-site on a project (and I personally think it's often a good thing) there can also be drawbacks. A company being large does not imply (especially in this day and age) that it is adequately staffed in all areas, or even (in some extreme cases) totally professional and/or organized. It is often vital for a small company to establish rules regarding its on-site staff up front; there are larger companies that will happily try and suck these people into projects that are not part of the contract (although they will often be dependencies in part blocking progress on the contract) but then balk at paying for the extra hours these additional tasks consume.
Plone Book
Professional Plone 4 Development

I am the author of a book called Professional Plone Development. You can read more about it here.

About this site

This Plone site is kindly hosted by: 

Six Feet Up