LavaBlast Software Blog

Help your franchise business get to the next level.
AddThis Feed Button

Collaboratively Defined Business Strategy

clock March 31, 2010 13:54 by author JKealey

 

bookingblast For those of you who’ve been keeping track, we launched LavaBlast Software back in April 2007. A year later, we posted three software startup lessons about how we got started and followed up the year after that with four more fun software startup lessons. Now that Year 3 is complete, I should write another set of software startup lessons, but that can wait. Today, I feel we’ve come full circle because we’ve begun working on the type of fun project that we would have enjoyed doing three years ago, but couldn’t afford the risk. In a sense, it feels like a full circle and a new beginning for LavaBlast even though we’re simply working on a new product.

BookingBlast is going to be legen – wait for it – dary. Read on to know more!

Starting from scratch

Pretty much straight out of university, we started LavaBlast Software. We had no money so we had to be creative. By creative, I mean we had to be cheap, work hard and work on something low risk to pay the bills.  The recipe for success is simple and we’ve said it before. Let’s just say we sell to businesses and we keep the intellectual property. This strategy has allowed us to start from scratch and making a living. 

We already have BookingBlast’s building blocks and now have enough runway to execute on our idea.

Ramping up

Some may stop here – but that’s not enough for us. We have greater ambitions - we’re looking for something bigger - for a greater reward. Based on the assumption that it takes a decade to launch a successful business, we’re not even a third through. We’ve passed through survival and have been growing steadily, but we’re now anxious to move to the next level.

We feel we can get there by converting the enterprise-level software we’ve been producing to date into more scalable Software as a Service (SaaS) products. We’ve been wanting to do this since day 1, but needed short-term revenues.  We’re now re-investing into LavaBlast to give us this flexibility. (I guess that visit to an unspoiled private tropical island will have to wait.)  We toyed with a few concepts during the past year, looking for software products that:

  1. No per-client customizations (greater scalability)
  2. Sold to businesses, not individuals (faster revenue)
  3. Shorter sales cycle, lower recurring dollar amount per sale (easier to commercialize)
  4. Related to our existing work and/or future strategies (reuse and upsell synergies)

 

Hold your horses! I’ll describe BookingBlast’s awesomeness in a minute.

Context & Goal

Our short-term goal with this project is knowledge. We’ve been building enterprise software for a while and want to dumb things down and start aiming for higher volume, but we need to adapt our know-how. We see BookingBlast as a practice run whereas our business is a marathon.

Our long-term goal is growth, in terms of revenue and the size of the company.  Lots of the enterprise-level work we’ve done can be commercialized to a broader market but we need a longer runway.

Spill the beans already! What’s BookingBlast?

BookingBlast allows service-based businesses to accept online bookings. Reservations are accepted only during available time slots and deposits are paid online, in advance.

To clarify, our software will allow customers to:

  • Book your child’s birthday party online
  • Book mobile clowns/magicians/comedians online
  • Reserve a massage / spa services online
  • Book your chiropractor from their website
  • Book a photographer from their Facebook page
  • … and accept bookings/reservations in many other industries.

That’s it. It’s not rocket science. It’s been done already – there are many competitors in this space – the market exists. The barrier to entry is low. But that’s not stopping us, because we have a plan. What better way to test our plan than to go out and execute it?  The worst that will happen is sales will be lower than desired and we’ll still reach our short-term goal of knowledge. We’re not betting the farm on this – it’s a stepping stone in the context of our longer-term vision.

How did you come up with your secret master plan?

We understand that this is a marketing play more than a technical one. We’re not inventing a killer product, although we can be innovative in our implementation. We decided it was in our best interests to share our plans for BookingBlast with people from diverse backgrounds and get them involved in the process. Ian Graham of The Code Factory always says the engineering students/graduates from the University of Ottawa are more secretive than the ones from Carleton University and we decided to prove him wrong. We openly solicited feedback on Google Wave and at TeamCamp. In the end, we found that we’re not that crazy after all as this validated our initial opinions. We did discover a few interesting twists which we plan on using, however.

Therefore, our plan is not secret – you’ll hear more about it when our product will be in beta. However, here a few lessons we learned from our experiences with collaborative planning.

Phase 1: Internal research

We looked around to find competitors and market penetration strategies. We discussed this internally over a coffee and did our homework. I produced a one-page executive summary of my initial plans.

Phase 2: Feedback solicitation via Google Wave

We published a private wave and invited two dozen random people. We made sure to invite people who were not extremely close to us because their feedback would be biased. We made it clear that the participants could feel free to ignore us as we didn’t care to force anyone into open collaboration, especially if they were busy with their own work. We found that the people least close to us were the ones who contributed the most to the discussion. Within 24h, the discussion had grown to approximately 8 times as long as the original executive summary. Within the next 48h, the discussion grew a bit more, with a few late-comers giving their comments.

The early discussions were the most valuable. They brought in new elements and got everyone involved. They definitely changed our strategy. However, as the discussion grew, I felt that most people lost interest because there was too much to be read. The barrier to entry had been raised, which caused most of the late-comers to elect not to participate. Initially, we thought this was a bad thing as we wanted more feedback, but in retrospect, we feel that what needed to be said was said early on. Had we discussed the same material with each person individually, we would have elicited the same comments over and over. Redundant feedback is not useful (other than for validation) and is a huge time waster.

In conclusion, open collaboration is a great technique to elicit feedback very quickly. I am greatly thankful to those who participated.

Phase 3: Feedback solicitation via TeamCamp

jkjp Ottawa’s primary co-working location, The Code Factory, hosts a bi-monthly event initiated by Chris Schmitt called TeamCamp. Once in a while, TeamCamp will have a pitch night where the participants pitch their idea to the group and get feedback. This is a very informal round-table setup but you get to chat with interesting people in Ottawa. A few weeks ago, I pitched BookingBlast to the group. This was great validation for our online booking software, as it proved that we had properly thought it out. Some new strategies were put on the table, but the biggest lesson learned is that you don’t need to spend months thinking about your project if you’re agile enough to adapt it along the way.

Furthermore, we finally had someone stand up and say our idea wasn’t good enough, something we had been waiting for since we started planning BookingBlast. Given the small scale of the project and the low barrier to entry, I was expecting most people to shoot our idea down quickly. Maybe I watch Dragon’s Den too much and read too many angel investor/venture capitalist blogs. In any case, this brought forth great discussions where it appeared other individuals were reading my mind while defending our online reservation software for me.

We’re now ready to start implementing the project! (In fact, we’ve already started and it is progressing nicely!) 

We need your help

We’ve posted a basic information request page on our website. If you know business owners that would be interested in participating in our alpha/beta programs, please have them sign-up to our newsletter.  We’re approaching the market in a different fashion that what the competition is doing, so we’d love to talk to business owners directly.

Since a good portion of our readers builds software for other businesses, we’d also like to talk to web developers that manage business websites.

Also, feel free to share your thoughts on BookingBlast and how to make it work in the comments. We’re thinking of openly blogging about thinks like SaaS pricing and gathering data concerning some of our strategies for future discussions and commentary.



Simplified Chinese on Epson TM-T88IV Receipt Printer

clock January 15, 2010 14:27 by author JKealey

 

As you might know, our favourite teddy bear franchise is now opening stores in China. Since we’ve developed a fully integrated point of sale for the teddy bear industry, we’re helping them setup the first store over there. One of our challenges has been getting the receipt printer to recognize Simplified Chinese characters. We posted this issue on StackOverflow and contacted Epson support for the first time to try and resolve this issue but we ended up finding the solution ourselves. I’d like to share this solution with you (and some of the hoops we had to go through) as it might prove helpful to other point of sale developers out there.

 Chinese Teddy Bear Birth Certificate

For neophytes, using point of sale hardware is usually straightforward. We use the Microsoft Point of Sale SDK for .NET which is a .NET class library that interfaces with OPOS (OLE for POS). OPOS is the first widely-adopted POS device standard, allowing developers like us to write code that will work with hardware using a unified interface. I will spare you the details of how to get a handle on the printer (open it, claim it, enable it) and will focus on the actual printing portion.

string str = "this is a test";
PosPrinter printer = GetPrinter(); // open it, claim it, enable it. 
printer.PrintNormal(PrinterStation.Receipt, str);
ReleasePrinter(); // unclaim it. 
 

 

Easy enough?  This code worked for us for our stores in Québec (French), Spain (Spanish), and Denmark (Danish) and still worked for us in China when printing Latin characters, but all the Simplified Chinese characters appeared as question marks. 

Question Marks

The first thing to note is that you cannot use any plain old Epson TM-T88IV to print Chinese characters. You need the special multilingual version (which we have: TM-T88IVM). Second, you need to ensure that Epson OPOS sees it configured as the multilingual version, otherwise it won’t know it can print in simplified Chinese. In our tests, we were able to print to the printer via the sample application that comes with the Microsoft POS SDK.

Epson OPOS Configuration ms

Doing a bit of research, we found that we simply had to change the printer’s codepage (from 1252 to 936) for it to recognize the simplified Chinese characters. (Our CharacterSetList=255,437,850,852,858,860,863,865,866,936,998,999,1252 which implied that we could actually use this character set value. If we had not configured Epson OPOS to use the multilingual version, we would get an exception because 936 is not in the list.)

   1:  string str = "重新开始";
   2:  string str = "this is a test";
   3:  PosPrinter printer = GetPrinter(); // open it, claim it, enable it. 
   4:  printer.CharacterSet = 936;
   5:  printer.PrintNormal(PrinterStation.Receipt, str);
   6:  ReleasePrinter(); // unclaim it. 

 

However, this changed absolutely nothing. At this point, we contacted Epson support who could not help us. Our printer self tests showed the printer was capable of printing the characters, but we were still unable to print Chinese characters. Furthermore, the build-publish-test cycle was very slow because we did not have this printer on site (70 days to have it delivered from our regular supplier!) – we had to rely on our partner who was in China to help with the store setup. We tried dozens of things, but could not find the answer. We needed to have the printer on site – we had our partner ship one to us – it arrived three days later. We then decided to run another test:  printing the following website.

Some characters printed image

Interesting… some Chinese characters printed. But not where we were expecting them! I immediately realized it was encoding other (simpler) characters as Chinese characters. In this case, I took the first one above that was generated when the source string was ài. I did a few tests to confirm that àj, àk, àl were all printing different Chinese characters.

Having no knowledge of Chinese, finding the character’s unicode/decimal value in some character map was impossible for me. I had to reverse engineer the problem. 

  • à = 0xE0 in hex = 224 in decimal
  • i = 0x69 in hex = 105 in decimal
  • ài is therefore {224, 105} as confirmed by
byte[] source = Encoding.Unicode.GetBytes(text);

 

I looked up 0xE069 but found it was nothing. I then reloaded one of my old tests to convert this byte array to Code Page 936.

   1:  // simplified chinese
   2:  var encoding = Encoding.GetEncoding(936);
   3:   
   4:  // convert the text into a byte array
   5:  byte[] source = Encoding.Unicode.GetBytes(text);
   6:   
   7:  // convert that byte array to the new codepage. 
   8:  byte[] converted = Encoding.Convert(Encoding.Unicode, encoding, source);

 

Looking in the resulting byte array, I saw {145, 6}. However, converting this byte array back to a string and sending it to the printer did not work. It did not work because I was simply reconverting it back into a Unicode string (C#). I also did not have a PrintNormal method I could call that would accept a byte array. I therefore computed the decimal value of {145, 6} (256 * 145 + 6 = 37126) and looked it up to see it was indeed the character I was looking for ()!  I therefore implemented an ugly byte-by-byte conversion and sent it off to the printer. It worked!

   1:  StringBuilder builder = new StringBuilder();
   2:   
   3:  // simplified chinese
   4:  var encoding = Encoding.GetEncoding(936);
   5:   
   6:  // convert the text into a byte array
   7:  byte[] source = Encoding.Unicode.GetBytes(text);
   8:   
   9:  // convert that byte array to the new codepage. 
  10:  byte[] converted = Encoding.Convert(Encoding.Unicode, encoding, source);
  11:   
  12:  // take multi-byte characters and encode them as separate ascii characters 
  13:  foreach (byte b in converted)
  14:      builder.Append((char)b);
  15:   
  16:  // return the result
  17:  string result = builder.ToString();

Thanks to other Stack Overflow users, I found the following concise implementation.

string result =  Encoding.GetEncoding("ISO-8859-1").GetString(Encoding.GetEncoding(936).GetBytes(text));

Thus, it appears that although the printer supports multilingual characters, one needs to re-encode them in the target codepage and then back into Latin-1 encoding for the Epson TM-T88IV Multilingual to detect it properly. The only things left for us to fix was the string padding (because these characters are twice as wide as latin characters on our printer) and finish off the receipt translation before the grand opening.

Success!

As a side note, if any of our readers have experience with controls (ActiveX or other Windows-specific applications) that allow to print to receipt printer, control the cash drawer, and receive barcodes from a barcode scanner from within a web browser, Flash, or Silverlight, please let us know.



Software Startup Lessons (Part 5) - Being a software startup in a recession

clock April 6, 2009 10:47 by author JKealey

Leigh Hilbert Photography captured a Lava Blast! We're six months late to inform people that you can/should still start a software company in a downturn as this has been covered already here, here, here, here, and here.  Why are we six months late informing you of this, you ask? We have been incredibly busy building software for our existing / new customers during this period. For reasons left unexplained, we've seen the number of leads in our sales pipeline increase dramatically since the start of the recession. Furthermore, people have been coming to us for consulting services thanks to the reputation we've built since we launched LavaBlast.

If we had to name a single element that has helped us / will help us during the recession, it would definitely be our capacity to discover commonalities between seemingly different situations, abstracting them out and generalizing the problem. We can build systems for people who may not be in the franchise industry, but have similar needs. This lengthens our runway. This is one of the skills that we learned in university (more on this subject in Part 7).

If you take a deeper look at what LavaBlast does (building customized software that helps collaboratively manage a franchise) it is easy to notice that we're solving a problem in a particular vertical that is present in numerous other business contexts. We build operational line-of-business applications (aka help-me-perform-my-daily-tasks-easily software) that are used by franchise owners and franchisors (aka different-users-can-see-different-parts-of-the-data-while-sharing-some-of-it software). Without going into greater detail, many businesses are looking for software that helps them simplify their day-to-day operations and reduce costs, recession or not. It might not be as scalable as a consumer-focused website and not as glamorous as other projects, but it does have its challenges and is a great type of business that one can bootstrap!

[ We'd like to thank Leigh Hilbert for the "Lava Blast" picture seen above. ]

 

A mix of software products and services

In the Part 1, written last year, we describe how LavaBlast builds products (franchise management solution, franchise point of sale, etc.) but also services (as we adapt our software to each franchise's business processes). To help sustain development in a bootstrapped startup, software consulting is often a necessary “evil”. This year, we did do some consulting but managed to make the best of it. We've made a few interesting realizations that we've shared at a recent TeamCamp event at The Code Factory and would like to re-iterate here. This discussion assumes you're building software for other businesses instead of consumers (for obvious reasons, it is easier to bootstrap a software startup that targets businesses).

Typically, software consulting companies produce the same kind of software a couple times for different clients before deciding that it would be a good idea to build a product that addresses this same problem. At this point, they've delivered source code to each of their customers, as the customers retained the intellectual property rights related to the produced software. Therefore, to build a product and commercialize it, the consultants need to start from scratch. Although this may seem bad as the firm loses time and money rebuilding the product, it typically allows them to “build it right” thanks to the lessons learned during the first iterations. The product's architecture is well implemented as the main variation points have been clearly defined.

Simply put, we did the opposite and have kept the intellectual property rights from day one. (How? We got lucky that our customers had limited funds to invest and knew the value of intellectual property.) We sprinted for over a year building the core of our solution that allows retail stores and e-commerce websites to communicate with a centralized franchise management application. This was a large undertaking, but we had our first customer already using the product and paying for its development, while we kept the rights to the source code. (Note: we still did multiple iterations and learned from our mistakes!) Once completed, the core was easy to adapt to different franchise systems because we're experts at rapid application development and because our core architecture allows us to vary software behaviour for each franchise (thank you the strategy design pattern and dependency injection!).

What's interesting to note here is that because we own the intellectual property for the core of our system, it is much easier to sell enhancements to our core (to new customers) while preserving the rights to the source code for the combined system. It is also easier to find new customers because the core is already built. Simply put, investing a year into a software product is an investment that keeps on giving, even in the services arena. Because we have a flexible core that has already been implemented and we're keeping the IP, it helps us keep costs down during a bad economy. This is a win-win situation for both parties!

Advantages for the software startup

  1. Retain the intellectual property
  2. Build applications faster, giving you time to work on other things
  3. Keep costs down - easier to find clients in bad economic times

Advantages for the client

  1. Lower cost
  2. Put the software to use quickly
  3. Lower project risk

 

To get back to the discussion we had at TeamCamp, the question was how do you turn your service business into a product-based software startup when you have limited/no funds, have limited/no leads, and own limited/no intellectual property? Well, I'm sad to say it, but it “sucks to be you”.

You have to break the perpetual cycle you're currently in and do something different.

For some people, that means realizing that you're never going to make a decent living building static websites for $200 when you've got to spend 20 hours with the customer to figure out where they want the pictures of their puppies on their upcoming site before actually starting the work. Your competition is doing it at half the price with pre-built templates, stock photography and, as an added bonus if you order within the next 24h, offering them a box of branded pens, 500 full-colour business cards and a mention on their next Twitter post. You are a commodity.

For others, the decision boils down to what short term loss can do accept for possible future gains:

  • Build a product, build your reputation, and try to sell enhancements to customers while retaining the IP.
    • Tradeoff: money. You don't earn much revenue while doing this (often nothing during the first months). If you don't have prospects and don't know if your idea is any good, this is risky.
  • Assuming you can't afford this, build something during weekends and evenings and reap the rewards when it is complete.
    • Tradeoff: time. It takes five times as long to build it. However, you aren't screwed if things don't work out because your regular work pays the bills.
  • Build a quick alpha version and see what happens. Spark interest? Find funders? Find partners? Abandon your crazy idea?
    • Tradeoff: features & quality. It is preferable to fail quickly if you are bound to fail. I'd prefer investing a week of my time and getting proper feedback from peers informing me that my product idea sucks and I am bound to fail than eating cheap noodles for six months before discovering than no one will buy my completed product. Talk to people at events like TeamCamp or DemoCamp - stop being scared someone will steal your idea. Don't ask Mom or your beer buddies as they won't be harsh enough on you (although some of them might be mean drunks!).

One tip that we do want to give fellow bootstrappers out there is that, in the early days, you can give the customer a non-restrictive copy of the code, while retaining ownership for yourself. That way, both parties have a copy of the source code and both parties can do whatever they want with it, including selling it to others. However, you're the developer and the customer has better things to do than commercialize your software: all they care about is being able to maintain the code when your contract with them is over. This is a win-win situation for both parties, especially when you've managed to collect various modules that you can re-use for different customers.

How to launch a software startup in a recession

(Precondition: Start something that you can sell to businesses to lower the risk. )

  1. Find a first potential customer. Sign contract that says the intellectual property is yours but they get a copy of their version and they can do anything with it.
    • At this point, your software is worth nothing more than what the first customer is willing to pay for it.
  2. Take your core software and refine it with other customers.
    • This time, try to keep the source code to yourself, as it is starting to build value.
  3. Repeat step 2 until you've got enough funds and a high quality product.
    • Your product is now valuable. You are now out of the perpetual cycle.
  4. Sell copies and grow your business
    • This is where LavaBlast is at now, after two years.
  5. [insert secret sauce here]
  6. Success!

 

Conclusion

Considering all that has been said about launching a software startup in a recession, I think it all boils down to asking yourself "is this the right time for me?". Software startups / Micro-ISVs are tiny in comparison to what's going on at the macroeconomic level. Before taking the risk to launch your own business, what matters is the presence of the following elements:

  • Dedication / Passion / Interest
  • Capacity to execute on the idea
  • Support (family, friends, partners)

kick it on DotNetKicks.com



Spolsky's Paradox

clock May 2, 2008 13:42 by author JKealey

Last week, I loaded up my blog aggregator and I was pleased to see Joel Spolsky had written a new article on architecture astronauts. He made a good point about how Microsoft is rewriting the same software over and over and no one seems to care. I totally agree with Joel's argument about architecture astronauts as we are wasting precious intellectual resources and solving the same issues over and over.  (Side note: an interesting read about how we're wasting massive amounts of brainpower.)

However, that's not what I'm writing about today. I found myself reading faster and faster as I progressed through the article, reading the last paragraph at a frenetic pace. You can definitely feel Joel's frustration - the big boys in the industry are "stealing" all the great programmers by offering starting salaries leagues above what smaller companies can offer. Why do I think Joel's frustration is paradoxical?

Joel's Premises

  • Hire only the top quality people
  • Treat your employees as if they were superstars in your beautiful New York offices - spare no expense.
  • Build a closely-knit team that works on challenging problems to retain your employees
  • Set an example as being the best damn place for a software engineer to work and inspire millions of developers to follow your example.

Joel's Aspirations

  • Recruitment problem: solved.
  • Develop and commercialize high quality software
  • Thanks to a well-defined (and very selective) hiring process, retire from software at age 45 to start your own avocado grove as a hobby.

The Contradiction

Okay... I'm generalizing just because I find it ironic to see Joel having hiring woes. Even if as a general rule things are going well, that doesn't mean you get anyone you want. Everyone has hiring frustrations, even those who set the example. However, I'm left to wonder... has anything changed in the context of hiring? Is there anything you need to do differently today to grab the best technical talent? I can't answer these questions myself, but I see lots of companies struggle with hiring.

I do agree that it is impossible for smaller companies to compete with some of these starting salaries (unless they are keen on burning VC money) but smaller firms do have (many) advantages. But what are they?

1. Get back in the kitchen and make me some pie

What I like most working for a startup (and it would be the case even if it wasn't mine) is the opportunity to touch a bit of everything (engineering, marketing, sales, legal, etc.). Even if you go work for a 40-person startup, if you're interested in contributing to elements which aren't related to your primary function (software developer), you probably can help out. For example, if you think the company's website doesn't communicate what the company does, you can take a step back, think about it a bit, and propose enhancements. (Complaining doesn't bring you anywhere, but constructive criticism helps everyone out!).

If you're a hardcore coder, you can still benefit from working for a smaller company, because you'll have a greater impact on the final product.

However, this fact is not something that has changed in the hiring context... what has?

2. Not everyone wants to work in New York, Redmond or Mountain View.

This is one key differentiating factor for startups. Not all of the world's most talented individual feel inclined to move to get a job and I feel the number of people who will start their own software business in their home town will increase in the coming decade. In the past, we've seen a few companies such as Eric Sink's SourceGear in Illinois do well even if their offices are in the middle of nowhere, so to speak. This is due partly because of increased high-speed Internet availability combined with the lower cost to start your own software business. I think we'll definitely see more success stories from entrepreneurs living in non-metropolitan areas over the next decade because starting your own business (or working for a local one) is such an attractive alternative. It's funny how making it easy to go global causes the creation of many smaller local hubs.

On a related subject, I don't recall that many local startups trying to recruit us while we were software engineering students at the University of Ottawa... there were a few but we were mostly solicited by IBM and Research In Motion (leading to the infamous "hey! do you want a RIM job?" quote). If you're a competent student today, you should definitely look around at local startups that are working on interesting concepts.

3. You can read about it on the Internet

There are tons of people talking about their software startup experiences on the Internet and it's easier to actively participate in the community today than it was a decade or so ago. I can't really see myself connecting to a BBS with my 14.4kbps modem to learn about software startups. Today, you can find people with similar interests very easily but, best of all, you can learn from their experience.

Rather than enumerate a long list of advantages that you wouldn't bother to read, I'd like to ask you an open ended question.

What do you think will change in the way we hire software engineers in the next decade?

Please feel free to discuss in the comments. Ideas: Outsourcing? Co-working? Telecommuting? Nothing at all?

kick it on DotNetKicks.com


Software Startup Lessons (Part 3) - Marketing, Sales & Growth

clock March 25, 2008 08:11 by author JKealey

We invite you to read Part 1 and Part 2 if you haven't done this already. A few days ago, Paul Graham had the following to say about our type of startup:

In an essay I wrote a couple years ago I advised graduating seniors to work for a couple years for another company before starting their own. I'd modify that now. Work for another company if you want to, but only for a small one, and if you want to start your own startup, go ahead.


The reason I suggested college graduates not start startups immediately was that I felt most would fail. And they will. But ambitious programmers are better off doing their own thing and failing than going to work at a big company. Certainly they'll learn more. They might even be better off financially. A lot of people in their early twenties get into debt, because their expenses grow even faster than the salary that seemed so high when they left school. At least if you start a startup and fail your net worth will be zero rather than negative.

Paul Graham

Lesson 10) Listen to your customers

screaming customers Some recent blog posts loudly taunt readers with titles such as I Repeat: Do Not Listen to Your Users. Of course, this is all just a blogging strategy as the end message is simply to spy on users to learn what they are doing with your software, not just listening to what they say they're doing.

Founders At Work informs us that a critical lesson when starting your own software company is to obey your customers, not your thick 75 page business plan. If they repeatedly ask for a module which you didn't plan for, and they're offering you money to build it, do it. It is not uncommon to read about companies starting out with a particular vision, building some internal tools to help them produce the target software, and ending up selling those internal tools instead. The original vision died, but they still built a successful company by being flexible and re-orienting their strategy depending on what the market dictated.

We lived this lesson first hand because our website was visited every day by independent store owners, looking for a particular piece of software. Even if they saw it was a solution for franchisors, they contacted us, wanting to purchase the software. We initially declined, but after thinking it through, we launched a side product targeted at independent stores. For our company, it's easy to spin-off products to target retail stores by cutting off all the integration built into FranchiseBlast. In our eyes, the product doesn't have the same value but, outside of the context of a franchise, it is a viable option.  Who knows, we may branch into software for independent retailers in the coming years (but I prefer our niche :) ) For now, it's a simple sideline to fund our core development. We also confirm the fact that it takes three times as long to develop a product as it does to create it for a single customer.

Furthermore, because we're self-funded, I feel we have a competitive advantage over our VC-funded competition. Our competitors want to skip the flat part of the growth phase and jump directly into the areas of highest ROI. Generally, this means developing one-size fits all software with (if you're lucky) tons of configuration options. We're not attacking the problem in the same way because we're building our architecture organically, refactoring when necessary. In the end, we don't tack on features, we analyze franchisor business processes and produce good solutions for them (both from an engineering perspective and a customer satisfaction perspective). This added personalized touch and desire to adapt to their operating environment is our competitive advantage.

Lesson 11) Software Sales

Because we're a small startup lead by developers, and because we think it's good for us, our developers do a little bit of everything which includes helping out with software sales and marketing. One of our partners is our salesman for the larger projects, but we're still actively involved. We've launched a small software product as a sideline because we had been getting inquiries for it on a weekly basis. It's something we already had and could launch without taking precious resources away from our main focus.

Here are some of our conclusions, from our perspective. Simply put, put yourself in a position where people want to purchase something from you as soon as possible.

Pushing your product is very hard.

Sending emails to potential customers: this generally does not work. We never send out mass mailings; we've spent a few dozen hours navigating hundreds of franchisor websites and picked half a dozen that we feel we could truly help. The experience was enlightening because we could extract patterns from the our potential clients' websites. However, in 2008, getting replies for an email is much harder than it was a decade ago when we first started our web design business. Spam has ruined email for people like us who take the time to write precise, customized emails. Back then, people didn't get that many emails and took the time to reply. Today, most people don't take the time to reply.

Cold calling is an arduous task and although the return on investment varies per product and industry, it is an essential part of business. Anyone can do the job but even professionals find it hard on one's self-esteem. Persistence is key.  For more tips, read this article

The long tail effect is very real, people come to us.

An insightful (and motivating) book is Chris Anderson's The Long Tail. To summarize the book in a sentence relevant to this section, given the negligible stocking/distribution costs of software and the ease of which we can search through the very large selection of different software which can be found on the Internet, it is now possible to create profitable businesses by developing software that targets a very precise niche. Simply put, create quality software that solves a particular niche's problem and people will find you, thanks to the Internet. We've experienced this first hand and confirm it is true.

Reality is a bit more complex than a simple if you build it, they will come, because you need to need to know your niche, work on marketing, getting in the search engines, figuring out the right price, etc. A more precise (yet recursive) statement would be if you build and promote something worth buying, they will buy it. In any case, in our first year, we reinforced our preconception that it is much easier to sell software to someone who comes to you than it is to push your software to someone who's not interested.

Karma: the simple solution for software engineers

Work hard and build a quality product. Assuming you are working on something with a reasonably sound business model, you're number one priority should be your product. There are lots of things to think of concerning marketing and sales, and you'll slowly learn to understand them if you have an open mind. In most contexts, writing good software is much more difficult than learning the ground rules of marketing and sales. Work hard, be honest, be open minded, and good things will happen. (Also, keep an eye out for the many people who don't follow these rules and try to screw you! :))

Lesson 12) Finding Other People

Running your own business is all about contacts (pretty much anything is!). At some point or another, you'll need to hire someone, partner with other companies, and find people to sell your product or services to. The more people you know, the better it is. You need to know people (and people need to know you) to be able to grow. We spent the biggest part of our first year working hard, undercover, and this was one of our mistakes. We weren't really trying to be undercover, but we weren't doing anything for people to know we existed. It took us a while to bother throwing our website online because we were so busy with our projects. Bad decision. The sooner your website is online explaining what you do, the sooner it gets on Google and the sooner people start finding you. Today, our blog (even if our readership is limited) helps us find and collaborate with many other people. We weren't sure what to talk about at first (we still aren't!) but we're having tons of fun.

Coworking

image We just learned about Coworking last Friday and it's something really interesting!  Here is a quote from the Wikipedia entry that best describes what Coworking is:

"Coworking is an emerging trend for a new pattern for working. Typically work-at-home professionals or independent contractors or people who travel frequently end up working in an isolated way. Coworking is the social gathering of a group of people, who are still working independently, but who share values and who are are interested in the synergy that can happen from working with talented people in the same space."

We have been working from home for the past year and it can sometimes become difficult to spend your days alone.  We are communicating continuously inside the company, but sometimes you need to see people! Here in Montréal, we have Station-C that opened on February 4th 2008!  It is definitely not as expensive as renting your own office and you get to see more people right away, to exchange and make new friends.  When you work from home, the possibilities of making new friends at work are pretty limited even if you have 400 of them on Facebook!

Networking

Networking is definitely something every entrepreneur should develop.  Here in Montreal we have the JCCM (Jeune Chambre de Commerce de Montréal  / Young Chamber of Commerce of Montreal).  Software engineers are not renowned for their social skills, but we're still businessmen so we have to make new contacts and meet new people!  What is nice with the JCCM is that you can network with people who are in the same situation: they are starting new businesses and/or are working from home.  You can meet people that have the same problems as you do and can collaborate to help each other.  Furthermore, networking with people of the same age group may help you develop professional relationships that will last throughout your career. Networking is a crucial part of any business and can improve the way you solve problems because you know who to call when something happens. As with anything, finding a good balance is essential (you need to find more experienced mentors!).

Business Plan

Before launching our company, we worked on a short business case and participated in a Technology Venture Challenge. We didn't win, but it was a very beneficial experience because sitting down and thinking about what the hell you're trying to accomplish is a very rewarding process. We wrote the plan for ourselves, but we had the chance to talk to top technology entrepreneurs, investors, and business professionals.  They helped us drill down and learn our strengths and weaknesses. Recently, we wanted to repeat the process and found a local full-length business plan contest. Again, the contest is a simple external motivation to get things done by a particular date but we're doing it for ourselves. Hopefully we'll get to meet more interesting people and it will allow us to grow as businessmen. We strongly recommend writing a business plan, but only if you're going to do it right, for yourself. If you're going to botch the process, don't bother. The most valuable part is the forced introspection; if you skip that, you'll simply produce a useless 50 page document. 

Hiring

We expect hiring to be our next challenge and are very inspired by Joel Spolsky's book on hiring. We're not too sure how applicable his strategies are in the first years or when you're not located in a metropolis, but it is good to have something to aspire to.  We expect to grow the team at the end of the year, and we're already looking for great candidates. Interested? :)

 

Conclusion: Infinite Number of Lessons

We could ramble on and on about things we learned during our first year. Simply put, the number of lessons are infinite.  We did perfect our technical skills but we did most of our learning in other areas.

Here are some lessons we could have talked about but chose not to:

  • Keeping up to speed with technological changes
  • How automation/scripting helps you save time
  • Don't forget the legal issues! Contracts, open source licenses, copyright, trademarks, etc.
  • The importance of a great web hoster
  • Versatility is key

We may post other lessons in the future, but for now we plan on creating a few technical posts with sample code. Be sure to let us know what kind of posts you like to see on our blog!

kick it on DotNetKicks.com



Software Startup Lessons (Part 2): Communication and Collaboration

clock March 17, 2008 09:39 by author EtienneT

Welcome to part two of our three part series describing the various lessons we learned during our first year of a software startup.  You are encouraged to read the first part if you haven't already!

Problem Statement

In Part 1, we described our business' context and how we eat our own dog food. Indeed, we use the software we produce on a daily basis, helping us create quality products. A parallel can be made with our distributed team's communication patterns. Simply put, we're not all at the same central office, talking to each other all day. Our structure resembles that of a franchisor with franchisees distributed a several physical locations. The main reason we are distributed is to keep costs down while we develop our core infrastructure, but it does have the interest side-effect of forcing us to use the same communication tools a franchisor would.

Not only do we not work in the same building, we're not even in the same city! Because we work in independent offices, we have a greater control over our environment, which increases our productivity. Spolsky often talks about how developers should have private offices because outside disturbances kick us out of our zone. You can respond to your email every 15 minutes, but you can't make someone wait at your door for 15 minutes while you polish off a complicated algorithm.

In any case, given the fact that most geeks are not social creatures, you probably think that doing the majority of your interactions over the Internet is great, right? In reality, it's not always convenient  but we've started to become really creative (and efficient) with the tools we found to maximize our interactions.

We spend most our time chatting coordinating on Google Talk and move to Skype when voice conversations are required. Over time, we discovered some pretty nice software to communicate and we want to share these tools with you in this article.

Problems:

  • How do we talk to each other and with people outside our company?
  • How do we exchange files?
  • How do we manage our requirements?
  • How do we demo our software, how do we program in pairs?

Lesson 4) Talking to People

Carrier pigeons might have played a vital part in WWII communications, but we're using more modern techniques.

Skype

imageSkype is the obvious choice for voice communication over Internet.  Don't tell us that you haven't heard about this tool before!  Because we are four partners in LavaBlast, we often need to have conference calls. All our meetings are done online via Skype conference calls, at no cost to us. Furthermore, we can call up a client on their regular phone using SkypeOut.  SkypeOut will call the client's real phone and will connect them to our conversation, at very affordable rates. Indeed, for $3 a month, we obtained unlimited outgoing calls to Canada and the US. Setting up a conference call is really easy and the quality is good (most of the time).  You simply need a good microphones and you're good to go.  In addition, if you have a webcam and a good Internet connection, the video quality of Skype is just amazing especially compared to MSN.  Talking to someone who also has a good webcam and a good Internet connection is almost lag free, in my experience.

Having a central phone number for a distributed office

Since we have a distributed office, we need to have a central phone number.  The most affordable solution that we found was Skype for business.  Basically you simply need to register a SkypeIn number anywhere in the US (not available in Canada yet) and when people call this number, it calls you on Skype.   The cheapest way to get your incoming phone number is to purchase Skype Pro (at $3/month) and purchase the number for $38 a year (and it was operational within minutes of purchase!). You can forward calls to another user or normal phone and even get voicemail with Skype Pro. Optionally, you may install the business version of the Skype program for additional functionality. Therefore, all the incoming calls go to our main salesperson and, if more technical details are required, the call can be forwarded to us.  Skype for business has a nice business control panel to control Skype credit purchases, phone number assignments, and much more. Additionally, because the phone number is associated to the company, we can redirect it to a new person if an employee is replaced or if someone is on vacation. We could have a 1-800 number, but I don't think we have the kind of call volume that would justify having one just yet.

We found the perfect phone number for LavaBlast: 1-201-467-LAVA (5282).  SkypeIn personal has a nice interface to check if a number is available, but the business panel interface doesn't.  If you want to purchase a specific number, I wish you good luck because you have to generate the numbers one by one!  We wanted a number that ended either with BLAST or LAVA;  we found the number with the SkypeIn personal interface and then tried to regenerate it, one number at a time, in the business panel.  We finally found one that ended with LAVA but couldn't find one that ended with BLAST.  The best way we found to generate multiple numbers was to press Ctrl and click like crazy on the generate button to open new pages in new tabs.  We eventually found the number we wanted!

Lesson 5) Exchanging Files

There are lots of cool startups focusing on better ways to exchange files and we're keeping an eye on them. For now, here's what we're using.

Subversion

As software developers, we obviously use source control to manage our code. No surprise here. We even deploy our web applications using Subversion.

FranchiseBlast

image We've developed a document repository in our franchisee/franchisor collaboration solution. We post our user manuals and a few other documents on there; it is our distribution center for completed documents.

Microsoft Groove

We use Microsoft Groove which is a party of Office 2007, as our main internal document management tool. Groove is much more than a document repository, but we only use this feature.  Groove is simple to use and install because it distributes the files on all the peers instead of having to setup a complex server. Furthermore, it is better than a shared network drive because it has change notifications plus it can be accessed even when you are offline. There are a few drawbacks, but in general, it's a good simple solution for the low volume of Office documents we work on. 

Lesson 6) Requirements Engineering

The first post on the LavaBlast blog was related to requirements engineering and how we managed our pile of requirements written on the back of (sometimes used) paper napkins. More seriously, we've found it very beneficial to collaboratively define our software requirements with our clients. Constant feedback is the key to writing good requirements, and using collaboration tools is a must.

Wikis

We've been playing with ScrewTurn wiki as our main wiki over the last year, for both for our internal use and to interact with our clients during the requirements engineering process. It is very easy to install (trivial) and it is very very fast. Editing a page is very pleasant because it is nearly instantaneous when you save a page... it just feels blazingly fast. Furthermore, because it is a free and open source project, you get to spend money on Super Mario Galaxy instead.

During our software engineering capstone project, we used TWiki as our primary requirements engineering tool, a couple years before the strategy was discussed in IEEE Software. Although we've enjoyed ScrewTurn's simplicity during the last year, I think we're ready to revert back to the more feature-rich TWiki. Installation is a pain (less now than before), but the syntax much more natural. Furthermore, we already have the infrastructure in place (using page meta-data) to let us manage our requirements.

Lesson 7) Desktop Sharing

Today, sharing your desktop is an essential operation for any software startup. You can easily demonstrate applications to potential clients or perform pair programming, without having to be at the same physical location.

Lotus Sametime Unyte

Trying to explain something to someone over Skype is not always fun, especially when the client is not a technical person. Because a picture is worth a thousand words, showing software is much quicker!  During most of our first year, we used Unyte to do just that.  With Unyte, you simply have to start the application, decide which window to share (or share the entire desktop) and then send a link to the person (or group of people) that need to see it.  Recipients click on a hyperlink and load up a browser-based Java applet to see the shared windows. It's as simple as that.  The client doesn't have to install anything and it's fast! The host will receive an alert when the viewers can see his screen.  Unyte, used in conjunction with Skype, is really a great mix for meetings and sales demonstrations. We used the version for five people and it worked well, until we found Microsoft SharedView.

Microsoft SharedView

A few weeks back, we discovered Microsoft SharedView while it was still in beta. SharedView is similar to Unyte, but 15 people can participate in a shared session.  The only big drawback is that everyone has to download the software.  So if you want to quickly present something to a client, it's a little bit more complicated if they have to install it.  However, SharedView does allow any participant to share their desktop for the others to see (only one person can share at any given time). During a software demo, we used this capability to have the client show us their current point of sale! Additionally, the software gives other people the possibility to take control of the session and perform operations on the computer that is sharing an application. You can also share documents pretty easily with everyone and send chat messages, but we still use Skype for voice communication. We now prefer SharedView to Unyte when it is a possibility to install software on every participant's computer.

Lesson 8) Blogging!

We've been able to connect with tons of great people thanks to our blog, and have lots of fun perfecting our writing skills. We find that figuring out what to say (and what your audience is interested in hearing) is the hardest task when you start a blog. We still don't know if we should focus on giving away code or writing more experiences pieces like this one. Let us know!

BlogEngine.Net

Our blogging software, BlogEngine.Net, is simply terrific.  Free, fast, really easy to theme, has some good extensions and integrates really well with Windows Live Writer.  One of the main advantages for us is that it is open source and it is written in .NET, allowing us to perform minor behavior changes as needed.   It still has a few bugs that can be annoying, but from what we have seen so far, it is performing really well.  It supports multiple authors, an important feature for us because we have two people posting on the blog.

Lesson 9) When not to use communication tools

The most important lesson we learned during our first year of operations as a distributed development team wasn't a revelation but rather a confirmation of our expectations. Communication and collaboration tools are great, but technology doesn't solve conflicts. We're a closely knit team and have worked together for a number of years, greatly reducing the number of conflicts we may have. The conflicts we have are generally superficial, but as an example, let's consider an architectural decision where the two decision makers have divergent opinions on the best solution. Although instant messaging is great for efficiency reasons, it is not the best medium to argument on the merits of your solution. Indeed, we've all seen the politically incorrect "Arguing on the Internet is like running in the Special Olympics; even if you win, you're still retarded". The main problem is related to the lack of emotional expressiveness of concise instant messages or emails and since it is discussed in great lengths by very good authors, we'll leave a detailed analysis of the situation to them! As a side note, firing people via email might have seemed like a good idea for RadioShack, but we at LavaBlast shall stay away from such brilliant strategies!

Conclusion

Communication is the most important part of starting a business. Even if you're the only person in your company, you still have to communicate with your customers! We hope that you'll discover at least one cool collaboration tool today! Remember to come back next week for Part 3 of our series.

kick it on DotNetKicks.com  



Software Startup Lessons (Part 1): The Basics

clock March 11, 2008 08:49 by author JKealey

Jennifer, one of my high school friends living in Montreal, recently started her own hair salon. Her employees live in Boston and Florida whereas her biggest customer is located in New York. The previous declaration makes no sense given the industry, but it does make sense in ours! Software can be produced anywhere and delivered to customers worldwide via the Internet. Furthermore, our increased connectivity helps businesses target very specialized niches which would not be viable on the local market. (For an overview of the subject, please refer to the excellent The Long Tail.) We're pushing it one step further with LavaBlast, which we started about a year ago, because our team is distributed. We can be categorized as a bootstrapped MicroISV (less than ten people producing software products with no outside funding), and we'd like to share some of our experiences.

We love to read about other startups and why they succeeded, such as Jessica Livingston's Founders At Work, but we're even more interested in companies that failed. On one side, it is very motivating to ready books such as Founders At Work and learn how the guys behind Hot Or Not started it all and got lucky with a very simple idea. On the other hand, knowing more about failures helps you learn from other people's mistakes. Books like Facts and Fallacies of Software Engineering helped, but were are not start-up focused. IMG_2940 If you're considering starting your own software startup, do take the time to read up on why startups fail, even if it is not the subject of today's post.

I hope you'll enjoy reading this series of posts and will be unable to resist posting comments and starting interesting discussions. Part 1 focuses on the basics, Part 2 revolves around communication, and Part 3 talks about what we've learned concerning marketing, sales, and growth.

Our Context

LavaBlast Software was started by two recent graduates from the software engineering program at the University of Ottawa in Ontario, Canada. After the bachelor's degree, Etienne moved to Montreal because of an attractive employment opportunity while Jason completed his master's. Both have been programming since their early teens on a wide variety of software systems in their various positions at companies of all shapes & sizes. From tiny web design shops, to medium-sized software firms in the electric industry, to second language schools for civil servants, to large Government departments, the founders had the chance to play with software from two perspectives. One one side we have small software companies who live and breathe software and on the other we have large-scale businesses in which most people are not necessarily computer-savvy (except for the IT departments). Additionally, we sidelined as male strippers at bachelorette parties, to pay for our university studies.

It did not take long to discover that we were so passionate about software that we wanted to start our own software company, not work in corporate Dilbert-reading sweatshops. Of course, this is simply caricature, as we worked on very interesting/challenging systems while in larger companies. There's nothing wrong with working in IT departments, but it wasn't a fit for our entrepreneurial drive. On top of that, we love working on projects where we get direct feedback from our customers, instead of internal company tools.

It was clear we were to start a software company, but did not know what nor when. The original plan had been acquire experience and a monetary cushion to allow us to start working on the next big thing. Before taking the plunge and leaving our day jobs, we wanted to have a good idea. We considered various ideas, but being recent graduates with student loans, going out on a limb and working with no revenue on a magical idea for an undetermined period of time was not a very attractive solution. However, we did find a very attractive business opportunity with people with whom Jason had been working for almost three years, on various web development projects. These partners have franchised their business and have acquired precious experience over the years. They are very knowledgeable and have a clear vision of the various business processes from the point of view of franchisors. After 20-some years in the business, they know what software is required, what to focus on, and how to support it.

Discussions ensued, and LavaBlast was formed. We produce industry-specific software solutions for franchisors. All our products are integrated via FranchiseBlast, which cuts down franchisor/franchisee costs at the same time as favoring re-use from a software engineering aspect. We have a base product offering which we tailor to our customer's specific business processes. In a sense, we sell software products with a side order of software services.

In summary:

  • No outside funding.
  • Small distributed team.
  • A mix of products and services.
  • We eat our own dog food.

Lesson 1) The Great Idea

Simply put, chances are you won't think of the next big thing. Even if you do, you probably won't have the resources, experience, or contacts, to turn your idea into billions. We were not expecting miracles but were on the lookout many months in advance. One thing we learned while reading Founders At Work is that many software startups are formed without the faintest clue of what the product/service will be. The most important part of the company is not the idea but the people. A small and closely knit team of people who've worked together in the past is a recipe for success, regardless of the idea. Indeed, execution is key! Partnering with people who have a track record of bringing ideas to reality is, in our opinion, the most important part of the business.

We are very happy that we did not wait on having a brilliant breakthrough idea and started our company immediately. We evaluated opportunities and picked the one that made the most business sense, knowing we can adapt along the way. Having made the plunge early in our careers, we felt we didn't have anything to lose because we didn't have that many constraints such as leaving a high paying job, a mortgage and student loans to pay, kids to feed, etc. The more acquainted you get with stable employment, the harder it is to leave. Still, it is worth mentioning that while we were very comfortable with our technical skills, our network of contacts is not as large as it would have been if we had been under someone else's employment for 5-10 years. On the bright side, we don't have 10 year of accumulated bitterness to carry around and we're in the best phase of our development careers (from a production standpoint).

Simply put, talk to people around you and reflect on what pieces of software would scratch your itch. There are business opportunities all around you... all you need to do is decide on what's the best fit for your current situation! Are you smart and can get things done? Are you able to adapt to your environment and pursue different opportunities when they present themselves? If so, don't wait for an idea that may never come and enjoy the ride!

Lesson 2) Eating your own dog food

It's been said time and time again, you need people using your software in order for its quality to reach high standards. Here at LavaBlast, we're fortunate to be able to develop UsWare because we're involved in our partner's the day-to-day franchise operations. As developers, we proactively solve problems before anyone reports them because we feel like we are part of the franchise. Furthermore, since we built our infrastructure to be re-usable, we recently launched SupportBlast as a clone of our FranchiseBlast solution. SupportBlast is basically our mini-CRM and we've integrated our software registration and license key generator in there. Although the strategy does have its limitations, using our own products helps us boost our software quality. Furthermore, for our kind of software, it would have been impossible to develop anything coherent without actual customers.

It takes ten years to build a great software product and it also takes ten years to become a software grandmaster.  You understand that quality takes time and effort and you'll only discover your software's weaknesses by listening to critique. It's better to be harsh on yourself than listening to someone scream over the phone, don't you think? 

Lesson 3) Mix of products and services

As stated previously, our company has currently received no outside funding (nor have we invested millions from our personal fortunes). We doubt angel investors or venture capitalists would be interested in our company because we're not aiming for a 100:1 return on investment. We could change our strategy and go for an all-or-nothing gamble, but we're more interested in growing our company organically. We know our company can be profitable using our current strategy, but we understand that we are not going to be the next FaceBook and my guess is that your company might fall into this same category. More importantly, we agree with Spolsky's model of company growth, and aim to be profitable from day one.

The main question for our type of company is how can we pay the bills while developing our product? The holy grail for return on investment in our business implies no additional work on the developer's part to support a new customer. Microsoft doesn't need to make adjustments to Word to sell it to a new customer and FaceBook allows its users to change the content of their personal pages themselves. On the opposite end of the spectrum, a good web design firm will create interfaces from scratch, adjusted to the needs (and tastes) of each of its clients. In the end, we want to be a product company but we need to build good products (and accumulate a critical mass of customers) before it pays the bills. We wanted to start our business immediately, not work on it on weeknights and during weekends for a couple years. Because of this, we decided our main interest was our product line but we'd perform services on the side as short-term an income generator.

We were open to external contracts, but did not end up doing any work outside of our product line. We're very happy of this fact because the solution managed to sustain its development without having to dilute our efforts with side-contracts (such as bachelorette parties).

Conclusion

Have fun but expect a bumpy ride. If you're not happy in your own company, doing what you want to do, you have a problem. Still, as with anything, you'll have some good days and some bad. In a startup, expect a roller coaster of emotions because you'll certainly get very excited by a certain situation but crash & burn when it doesn't materialize. In addition, not all work is exciting. You're starting a company and you have to do everything yourself. Doing accounting at 11PM on a Saturday night is not my idea of fun. Generally, however, it is very gratifying to build your own company from scratch and if you're fit for the challenge, I encourage you to try it out! The worst thing that can happen is that you will fail, lose some cash, gain valuable life lessons, and go back to working for someone else (or start over with a new idea :)).

Come back next week for part 2!

kick it on DotNetKicks.com



Month List

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017

Sign in