Starting Software Projects

There’s a genuine wave of entrepreneurship happening in my country right now; I don’t know whether the same thing is happening elsewhere. What should be an attitude taught to children from kindergarten onward now seems to be something we’re learning at breakneck speed (driven by the urgency of the economic and financial crisis we’ve been dealing with for some time).

Magazines and publications, radio and television shows, master’s programs, plenty of self-help books on personal development and coaching, and programs to support entrepreneurs are everywhere these days.

I think all this is good because it means we stop thinking that other people are going to give us a job and take responsibility for thinking for ourselves—a concept some circles call personal empowerment. This attitude is also very positive as an employee: it’s what we call being an intrapreneur, someone who innovates or contributes ideas within their area of responsibility while working for a company, remaining proactive with themselves and everything around them.

Software developers may have an easier time than other professionals starting a business at a time when everyone is looking to the Internet and the economic paradigm is driving efficiency and the widespread use of always-connected devices. That’s why many developers constantly have ideas they want to pursue as business ventures.

Being a good programmer and mastering certain technology platforms have nothing to do with starting a sound business project that works commercially. That takes many other skills which, of course, can be learned.

What’s not good at all is ignoring the skills and knowledge needed to build a commercial venture. Not long ago, someone asked what I thought about this and what the first steps might be for turning an idea into a product. So this time I’ll go into more detail than usual and do my bit to outline what needs to be considered.

Hundreds of books, seminars, courses, and even master’s programs cover this subject, which evolves just like software technologies. So this post is something like a fast-paced introduction to starting software ventures.

Because it’s a long piece, I’ve divided it into the following sections:

• From idea to project
• You have to validate the idea
• Pivoting and improving the idea
• Branding and design
• Choosing technologies
• Deployment costs
• Defining KPIs (performance indicators)
• This is nowhere near the end
• Some final thoughts

From idea to project

In a way, entrepreneurship is about testing whether what you have in mind can work and finding a market for that idea or product. If the goal is to test something and then, based on the results, evolve it as many times as necessary, then this all sounds a little like agile and lean: iterating until you get a good result.

Mistakes are often great teachers. Back in 2008, I had my first encounter with an entrepreneurial idea and project that turned into a complete disaster after just a few months. We confused the idea with its execution, friendship with commitment to a shared project, and, of course, we had no idea how to give what we wanted to build a proper business structure, among many other mistakes… I remember that first failed project fondly for everything it taught me. It’s also true that failure is now often championed as a learning tool. I suspect the virtue lies somewhere between apathy and beating ourselves up whenever we stumble.

In any case, since then I’ve been around many projects started by people I know, heard talks at events about innovation models, and done a great deal of reading on the subject. I’ve also worked on personal projects with varying degrees of success.

If you’re thinking of launching an idea that involves developing any kind of software, I’d like to point out that the software itself is only the center of a universe of variables and tasks that need to be handled well. Some are related to software and some aren’t, but without that universe your idea won’t get anywhere, I’m afraid.

As developers, we like to spend much of our time programming, creating things that do something. But if we’re building a software-based venture, we can’t ignore the need to give it the right entrepreneurial structure. And, of course, we need to be prepared to spend a little money… That line about how they started with nothing is just an urban myth that may have worked for a visionary or two, but it’s by no means the norm. I don’t understand how someone can say they believe in their idea and then be unwilling to invest some money in it.

Let’s look at the fundamental pieces that enthusiastic software entrepreneurs barely consider or take seriously—and, above all, at how some software-related decisions are essential.

An idea, obvious as it may sound, exists only in your head.

What a surprise! In other words, if that idea doesn’t get out of your head and come to life through action, it’ll stay there, a mental construct with no value. Most people’s ideas stay inside their heads; only for a few is an idea strong enough to move them to action.

We often daydream about a wonderful, unique project that could work—that is, attract users and customers and therefore generate revenue. Then we make plans about how to do this or that, what technologies to use (often the ones we know best), the possibilities that might open up, and so on.

Sometimes these wonderful ideas are nothing more than mental fantasies that help us escape a personal or professional reality we don’t like. I’ve seen that more times than I can count.

If you’re a dreamer, stay in the world of ideas; only the ideas that lead to action, work, and effort will make it.

You don’t need to invent a wonderful, completely innovative project. Often, proposals that seem trivial or even boring are the ones that find a market and prove viable.

In my opinion, there are two key moments in moving through this phase (let’s call it from idea to project). The first is to sit down and write a clear description of the project, its mission, expectations, and so on. Writing down everything in our heads is invaluable, simply because it forces us to define things that until then were only vague abstractions. Many ideas don’t make it past this test…

There are techniques for putting a project idea on paper, such as the canvas technique, with online tools like Canvanizer to help define it. Mind maps can also help at this stage.

The second moment, if the idea makes it through the first, is making a commitment to yourself. No fledgling project is going to get built unless we first make a personal commitment to it—that is, commit to finding extra time (taking it from leisure, weekends, and so on). You only get somewhere when you’re personally committed. The amazing thing is that when you believe in something, the effort doesn’t feel like a burden, because you want to spend time on it.

At least that’s how it works for me: when we’ve finished a project phase on time, or completed any personal project, whatever it may be, my greatest satisfaction comes from having honored a personal commitment I made to myself.

If taking action is difficult for you, you urgently need The Art of the Start, by Guy Kawasaki.

You have to validate the idea

I like the lean approach to building projects, especially software-based projects operating in a fast-moving world where paradigms change so quickly. Disruption is what succeeds these days.

In a market saturated with everything, how can we find out whether the project we’ve defined can work? The days of making huge investments in long technology projects only to conclude, after they’re finished, that the idea was wrong or there was no market for such a wonderful project are behind us.

Why spend all our time and money just to find out whether something can work?

The lean approach is precisely about testing an idea early (and cheaply) in the course of building a project.

You shouldn’t just read these two books; you should study them: Eric Ries’s The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses and The Lean Entrepreneur. Both are easy to read and complement each other.

Design a basic, minimally functional product with the essential features needed to show your project idea and the problem it aims to solve.

Next, before launching it officially and globally, validate the product with a small sample of users. Those first users can easily be your friends, family, acquaintances, and friends of friends. They’ll tell you what they think and will probably give you invaluable feedback, because it will show you whether your idea can keep growing in the direction you expected, or whether you simply need to go back, rethink it, or throw it all away. If that happens, wonderful! You haven’t spent a tremendous amount of time and money on a finished product just to find out that nobody is interested, and you’ll have learned a lot along the way.

Basically, the lean approach to projects is about running experiments to find out whether your project idea works. Depending on the results, you either change the project (pivot) or conclude that it isn’t viable.

Until recently, testing the viability of a software project was expensive, but today it’s very cheap and you can do it yourself in your spare time. There are well-known examples, such as the founder of Groupon, who began by testing his idea with friends, family, and neighborhood stores.

If these early validation stages go well, then it’s time to grow: improve the product, look for partners (it’ll be easier if you have something tangible to show), find funding, and so on. In other words, we move from playing with an idea to taking it a little more seriously.

Looking for funding with a vague idea (or a huge business plan on paper) isn’t the same as showing a working prototype that clearly demonstrates what you want to build.

Also, before you’ve invested a lot of time and effort in your project, you can assess its viability based on the interest it might generate, very simply and cheaply. You can even do this before you have anything to show. How?

One way is the test of the infamous landing page: before building anything, publish a simple static website that clearly explains your purpose and invites visitors to give you some kind of feedback.

Promote that website even a little, and you’ll get feedback, comments, and suggestions—information that will give you a better sense of the project’s potential interest. Believe me: when you ask people, it’s surprising how many are willing to help, especially if they feel they’re helping someone.

Another increasingly popular way to validate an idea is to post it on a crowdfunding platform. If you quickly receive the funding you’ve requested, you’re probably on the right track.

Pivoting and improving the idea

No project enjoys unqualified success from the moment we conceive it until we publish it (unless you’re a visionary, of course). Usually, you build one part of your project idea and can only see how well it fits and succeeds after publishing it. That’s why we try to publish as early as possible, so we can learn and test its viability. This has always reminded me of software concepts such as continuous delivery and continuous improvement. In fact, the lean approach to project development is closely related to agile development—or, put another way, we don’t really launch products and projects to conquer the world; we launch them to experiment with the market and listen carefully to what it has to say.

Experimentation teaches you how to bring your product closer to a market that wants it. Learning from this experience lets you go back a little and pivot—that is, evolve your project to better reflect the feedback and everything you’ve learned since its first release. Perhaps you learn there’s no point in pivoting at all because nobody is interested in your product. That’s not bad; it’s wonderful, because you’ve discovered very early that your proposal isn’t viable (saving a lot of effort and money).

You pivot to improve your product, bring it closer to users’ needs and the feedback you’ve discovered, and deliver value continuously. What’s interesting about pivoting is that sometimes the market’s response sends your product down a completely new and unexpected path.

This cycle of experimenting / learning / pivoting / republishing isn’t something you do only at the beginning of a project; it’s the basic working philosophy that will stay with it throughout its life. After all, it’s hard to imagine Amazon with the same features and capabilities it had just two years ago.

There’s nothing worse than revisiting a website a year later and finding that nothing has changed; it gives the impression that the project has stagnated. Pathetic.

As I said earlier, the first tests (or experiments) can be done very simply with your family, acquaintances, and friends.

Branding and design

In an intensely competitive market (we’re talking about software products, websites, portals, mobile apps, cloud-specific development, and so on), with millions of apps available at the click of a button and a crowded web, how do you start making your project stand out from the rest?

You need to define everything related to branding—in other words, define your brand identity.

People often think this just means coming up with a name for your project, but branding is much more than that. There are even companies that specialize in providing these services.

Branding includes:

• Choosing the right name for your product or project.
• Checking whether the domain names are available.
• Checking whether companies with that name are already registered.
• Creating a strong brand image, including a logo, logomark, or a combination of the two.
• Giving your project a corporate identity.
• Checking whether the project name sounds good in other languages.
• And much more.

This work matters—a lot. Good branding makes it easier for your project to reach users; poor branding can get it ignored completely. Hiring a specialized company naturally comes at a cost, but not doing the work can cost even more.

So, should you do branding before or after? It depends on your type of project, your budget, and so on.

Not long ago, I attended a talk by Máximo Gavete, a branding expert with his own consultancy, Omixam Studio. That talk made it abundantly clear to me how important branding is.

Choosing technologies

Choosing the most appropriate technologies for a software project is an art in itself, and a decision that can hold the project back in the future. We usually choose the technologies we know best (which isn’t always the right choice).

You need to carefully analyze the project’s potential future scalability needs, the third-party APIs it may need to integrate with, its security models, and so on.

If you choose a technology you don’t know well, you’ll have to get past its learning curve before you can make productive progress on the project.

Depending on the technologies you use, deployment may also cost more later on (in licenses, more expensive hosting, and so on).

The choice isn’t easy, but I would suggest the following:

• If all you want is to validate an idea and gauge potential interest, work quickly with the technology you know best. If the response is positive, then revisit the project’s technical design.
• If you’re not sure you’ve chosen the best option, at least try to make certain parts of the system replaceable with other technologies or providers in the future (abstract data repositories not tied to a specific database, a lightweight frontend, and so on).

In short, use common sense.

Deployment costs

If you’re working on a web project, it’s obvious that you’ll have to deploy it so it’s available to users around the world.

Depending on the technologies you’ve used and the nature of the project, you need to consider deployment and operating costs—costs that are often ignored until the project is ready to launch.

The Internet isn’t free. Another obvious point, but deploying a project isn’t just a matter of finding a hosting provider; there are costs such as:

• Domain registrations.
• SSL certificates (which certainly aren’t cheap).
• Dedicated servers or virtual machines.
• If you deploy in the cloud, the cost of related services (databases, storage accounts, and so on).
• If your application sends a lot of commercial email, you’ll need to hire a provider such as SendGrid, MailChimp, or Mandrill.
• Data traffic. Although download and upload bandwidth is cheap, heavy traffic between users will add to your costs.
• CDN (content delivery network) services.

As I said, all this depends on the nature of the project, but it’s important to account for it because, along with other costs, it tells you the financial threshold you’ll eventually need to monetize.

We haven’t even talked about maintenance costs. If you think the project is finished once it’s published, you may be in for a big surprise. Databases need maintenance, cloud services need to be monitored, and if the project grows significantly in users, you’ll probably discover bottlenecks if you haven’t run performance tests. You also need to manage users who write through the contact form, make requests, or need help resolving issues, and so on.

I’m not trying to discourage you, but all of this comes with the territory.

Defining KPIs (performance indicators)

When we’re deeply involved in our project and see it from the inside, the worst thing we can do is imagine the impressions it’s making based on subjective comments or responses.

We need to validate the project using objective, simple, measurable data (KPIs). To do that, we need to define metrics that show as clearly as possible the level of interest it generates, while also properly managing comments, suggestions, and the project’s usability and functionality.

Before launching and experimenting with the first release, define which metrics you’ll need to assess the level of interest the idea might generate. It’s not enough to define them; you also need to decide how to implement them. At first, Google’s free web analytics may be enough, but it probably won’t be.

The right metrics depend on the nature of each project. Here are a few examples:

• Number of registered users per week. It may seem obvious, but if we see the user count growing by 5% each week, we’re on the right track—as long as those users generate a return at a similar rate.
• Time users spend on the website.
• Bounce rate (users who visit the website and don’t view anything else).
• How often users return.
• Obviously, if the website sells something, measure the number and types of products sold. If it sells physical goods, track orders, payments, and logistics with the shipping provider.
• The percentage of users who use each feature in the project. That tells us which things interest users and which don’t.
• And so on.

We don’t validate an idea with positive, subjective comments about it; we use measurable, as-objective-as-possible data—especially data that helps us improve the product, identify what is worth strengthening, and understand how it translates into revenue. It’s not easy.

This is nowhere near the end

By now, we have some idea of the huge, sometimes overwhelming gap between having a brilliant idea and putting it into practice—and this is only the tip of the iceberg. Addressing the topics I’ve covered very briefly puts us on the path to successfully bringing a project to life. In my opinion, publishing something to validate it and discover that it isn’t right is still a kind of success (we’ve experimented with the market, in lean terminology).

If you hadn’t considered any of these things before, I’m sorry to play devil’s advocate, but it’s important to understand what starting a project involves, with all its pros and cons.

But wait, we’re not done yet…

Everything above matters, but it isn’t enough. There’s still a long way to go, and we haven’t said anything about:

• SEO, SEM, marketing, sales, and social media. Depending on the project, you’ll need a management strategy for each of these areas. Yes, some projects have succeeded with hardly any sales or community-management work, but most need to take it seriously because it helps spread the word.
• Business structure. You can’t ignore legal matters when publishing something that involves financial transactions. Invoicing, keeping proper accounts, complying with tax rules, and so on all need to be considered from the moment you see that the idea has passed its initial validation phase.

Some final thoughts

Not long ago, someone asked me how to take the first steps toward an interesting project intended for the Internet. So here, very briefly, I’ve tried to outline the most important aspects of carrying out any idea or project as professionally as possible.

I’d venture to say that all these things can be learned almost as you go. In fact, I love the idea of learning by doing, as opposed to the paralysis by analysis I’ve also seen so often. We learn (and succeed) by acting, and only through action do we come face to face with failure and success, whatever those words mean to each of us.

We have libraries full of acclaimed, recommended books that can help us understand our shortcomings and save us months of work for very little money.

Without a doubt, getting a project off the ground is the best source of learning we can have.

The most important thing in bringing any project to life—and I say this with complete conviction—is making a commitment to yourself, especially if you’re doing it personally with little spare time because of work commitments, family, and so on.

Months of daydreaming and wonderful plans (including visualizing what you’ll do when this brilliant project succeeds) remain a simple, childish fantasy if we don’t sit down to work on a Monday at ten at night or early on a Saturday morning. The Internet is full of failures, but the number of failed projects is dwarfed by all the projects that never made it out of their owners’ heads.

Only people who take action make progress.