The other day I got an email from someone asking about being a founding CTO of a tech startup. I replied with some brief advice, but it got me thinking: I've been doing this for a decade now, and was creating projects on the Internet for a full decade before that. A hallmark of the teams I've been lucky enough to work with has been the ability to punch far above our weight: online magazines edited by 15 year olds that ended up being distributed by the established press; the number one linked-to site on Blogdex (remember that?); a social platform used by the most prominent universities in the world, as well as national governments and Fortune 500 companies; and a video platform used by some of the world's largest broadcasters. These are solid achievements for groups and companies that, for the most part, contained fewer than 10 people.

The web is rife with articles giving universal advice based on subjective experience. For whatever reason, there's a tendency for technical people to think, "this worked for me, so why aren't you doing things the same way?" I don't think that's usually truthful or productive, so take this post with a pinch of salt. These are my opinions, not a manual.

Nonetheless, if you're just starting out, with few resources, what advice can I offer? Here are a few things I hold to be true.

Enjoy yourself.

Few things are as exhilarating as creating your own thing from scratch - making something from nothing - and releasing it into the world. People will notice if you're loving the experience. Don't lose your joy.

Focus on people.

For "people", read: your end-users, your customers (if they're different), your coworkers.

Your satisfaction must come from pushing code to the user and building something that creates value, rather than the act of programming itself. If you don't like people, and you don't want to interact with people, don't found a startup. If you're starting a business, you need to be relentlessly social (in the human sense), communicate well, and love getting feedback. Otherwise, do something else.

This is a refrain I'll repeat many times below: communication, communication, communication. You need to communicate clearly, and you need to listen, both to your customers and your team.

This is, of course, in addition to having great technical skills. These things together will allow you to build great software.

Understand your responsibilities.

As a co-founder, you are jointly responsible for the direction of the company, and creating an awesome, valuable product.

As the technical lead, you have a lot of responsibilities and pressures on your shoulders. You need to make sure your product or service is technically as good as it can be. You need to ensure that the technical side of the operation is able to meet business objectives. You need to be a software architect, and an infrastructure architect, and a technical designer, and a lead developer. As you grow, you need to be a product manager, ensuring that everyone in the engineering team understands the business goals (and hits them), and ensuring that everyone in the business team understands the technical challenges (and has a sense of the technical realities of your projects).

Ultimately, the technical buck stops with you. If the technology doesn't work, it's your fault. That's fine, but it's therefore doubly important that you are candid with everyone in the team about technical challenges that you might face, and the requirements for success.

Pick the right cofounder.

Before you begin working on a startup, it's also important that you check if your business co-founder or co-founders are able to bring something to the table to the same degree. If you're doing all of this and picking up a disproportionate degree of the business side, you will find yourself quickly burning out, serving nobody. Be a cog, not the engine.

One particular danger is that people see you as someone who can make their ideas a reality; that you will, essentially, build what they tell you to. (In one particularly toxic situation I was referred to as "the back-room guy".) This is an employee relationship, not a co-founder one. The company needs to be a true collaboration between founders, and everyone must have the skills and focus to participate more or less equally.

An oft-quoted metric for finding technical cofounders is if they have a past record of building things under their own steam, and an understanding of the intersection between business and technology decisions. Well, guess what? That applies to non-technical co-founders, too. Do they have a past record of starting their own ventures? (They don't have to be businesses, but their own projects, and so on.) Do they have an understanding of the intersection between business and technology, and the kinds of trade-offs you have to make? They do? Great.

Build small pieces, loosely joined.

Don't fall into the trap of building elaborate frameworks or overly elegant technical solutions. Your role as a startup founder is to test and change rapidly. By building too much of a framework around your code, you lose the ability to react to customer feedback. The ideal is that you can learn as much as possible from your users, and then shift your code to take these things into account.

Nonetheless: always, always, always make sure code is commented and well-documented, no matter how little time you have to spend. Comments are part of the code, not an afterthought, and the people who tell you that decent programmers should just be able to read the source are flat-out wrong.

That you should use decent source control, issue management software, etc, is obvious. When you're starting out, a paid GitHub account should work fine. (I've used Beanstalk, Assembla, and a bunch of other things, and GitHub is more stable, is easier to use, and has the best ecosystem.)

Be proud of your system's code, but be proud of how small, nimble and well-documented it is. Don't be afraid to plug in existing, well-tested frameworks and libraries, as long as they're well suited to your goals.

Don't be trapped into caring what the cool kids think about programming languages. The only material way your choice of programming language will affect your software (within certain bounds, of course) is in the choice of people you are able to hire.

Remember design.

User experience, interaction and interface design will probably come under your remit to begin with. They are the first impression that your product makes. Don't make the mistake of thinking of them as an afterthought (or, as more than one developer has expressed to me in the past, "pretty pictures"). Design is equally as important as architecture. You need to make sure every one of your engineers - as well as the business team! - is thinking in terms of the impression the product you're all making is having on its users, rather than a list of features and capabilities. If you can, bring a professional in to help you with design. It'll make a disproportionate amount of difference (see my note about the team, below).

Expect to scale.

If you're building technology, build it with an understanding of how it'll work when it has 10,000x the usage it does now. A few years ago, there were a lot of articles warning about premature scaling, which is a danger: you can easily sink all of your time and resources into building infrastructure that scales beautifully, when your focus needs to be on shipping as early and as often as you can. Nonetheless, not paying enough attention to scalability is dangerous. The old programming maxim - never assume you're going to be able to come back to anything - certainly holds true in a startup. Ask yourself what'll happen when you exceed the capacity of one server, or five, or fifty. When scaling becomes a business need, you'll need to do it very quickly. You'll have to do work in each case, but if you've thought about it and prepared while you were building, you'll be much more agile.

Again: small pieces, loosely joined, with queues and late binding. You'll thank me later.

Don't skimp on tech, but don't waste money, either.

I've written before about my long, slow journey to Mac. I just think they're better computers: more reliable, faster, and, crucially, more compatible with the software you're probably running on your servers. They're not more compatible than Linux laptops, of course, but there you'll still run into a world of hardware incompatibilities and time-wasting fiddling that you really can't afford. Leave the tinkering to your spare time. The last thing you want to be doing is fiddling with drivers or mucking about with wifi settings when you should be working on your product or your next pitch.

Think about what you actually need. My first Mac was a 2011 Macbook Pro that I upgraded to 16GB of RAM; theoretically it's blazing fast. In fact, though, the computer I use the most is my Macbook Air, which is less than half the cost, and theoretically vastly underpowered. It just works, and the battery is impressive enough to last a coast-to-coast flight. These things matter.

On the other hand, don't buy a peripheral, or something like an iPod Touch, unless you absolutely need it to test or run your software. You don't need to be awash in computers and technology. Just buy the things that affect your business directly, at least to start with. Most of us are gadget-heads to some degree; resist the temptation to buy cool stuff because it's cool.

Strong milestones are good - but it's okay to change the plan.

A set of strong milestones, with associated tickets, allows anyone in the team to get a good sense of the roadmap. I like arranging tickets onto a kanban board, so you can see what people are working on right now, as well as the backlog. Standups are great for this, too, as long as you follow the rules and do it standing up, for a short period. Don't be tempted to devolve into a long meeting; that's not going to get you anywhere.

Sometimes, you'll find that you need to change the plan completely, perhaps to take advantage of a sales opportunity, or because you've realized you need to take a change in direction. Early on, that's both okay and sometimes necessary. You need to be okay with not sticking to the plan, and you need to reassure your team that this isn't a terrible thing. As ever, good communication is key, and it's a good idea to go into the "why"s.

Your team is everything.

When I was working on Elgg, we knew we needed a designer to help build better interactions and interfaces, and create the brand identity for the company. When we found the person we wanted, we paid him more than our own salaries; we had equity, after all, and adding him to the team would create a huge amount of value for the company.

Do your best to hire well, and never hire someone because they're cheap. Sometimes they won't know their own value and it'll work out, and sometimes you'll find someone who is genuinely under-skilled. Either way, by paying them far below market rate, you're screwing them, and that's a lousy footing to start off a relationship on. It's certainly true that you'll have to pay less than many companies, but you can offset that with the freedom that a startup can offer. (Equity and the promise of value later on isn't enough; at this stage, most potential engineers are wise enough to know that share options are a lottery ticket.) If you're creating a corporate, hierarchical environment with all the resource constraints of a startup, and not offering anything tangible in return as people, you're creating a poor working environment. Freedom, trust, and a creative environment are all motivators. It doesn't have to all be about money, although money really does help; salary should be one of the first things you bring up when you can. Employees who are worrying about making ends meet are needlessly distracted.

It's okay to let go of someone if they're underperforming. You should do it early, both for your and their sakes. Sometimes, it's just not a good fit. Nobody likes working somewhere where they're doing badly, and there's no need to be nasty about it; if it isn't working, it isn't working. It's better to end an unproductive relationship quickly than let it limp on. This is, for me, a very hard thing to do. Nonetheless, it's sometimes necessary.

Be nice, by the way. Steve Jobs was famous for yelling at people, and he wasn't alone. It's completely unnecessary, and creates a poor environment. You and your team are allies, and if something's going wrong, remember where the buck stops?

By the same token, your team has to know that if you're asking them to do something, it's for a reason. While you should always be open to the idea that you could be wrong, and interested in listening to opinions from your whole team, everyone does need to know that you have the final say, and that they need to be adhering to the milestones you've set down. (If those milestones are realistic, of course; you need to be receptive to the idea that they might not be.)

Hire well. Get people excited. Be a steward of their well-being, and give them the space to build amazing things. Don't dictate tasks; your team are your collaborators. Talk them through what needs to be done, and why. Smart people question things, so give them reasons.

One last thing: part of communicating clearly is making sure people feel like they can approach you to talk about anything. Your workplace has to be a safe place. If someone is being harassed, or feels put upon for any reason, or they have any concerns at all, they need to be able to talk to you about it without fear of reprisals. Similarly, they need to feel comfortable. If someone's making sexist jokes, or otherwise making anyone feel uncomfortable, it's down to you to stop it.

Everyone should do support.

By which I mean, everyone in the company. It's important to understand the problems your customers are experiencing, and this is a great way for everyone to get a good handle on that. But it's also important for everyone in the company to understand how the product works - something that non-technical members of the team might have less of an understanding of, as they're not in its guts day in and day out. By ensuring that everyone takes support phone calls (if you take calls) and emails, you ensure good product & customer knowledge throughout the team.

It all comes down to empathy.

Good communication is empathic. You need to be able to understand your customers, your team, and your co-founders, and react when you sense that any of them are unhappy. Tech startups may have technology running through their veins, but more than anything else, they still have people at their core. A little love goes a long way.

Good luck!