The LA startup scene is fascinating, having lived and worked in it for a year now - it's a scene teeming with brillaint people with big ideas, and it's starting to attract some major capital from the Bay Area. It has one major issue: a big shortage of technical co-founders.

As a result, people like me get approached fairly regularly by companies that are either trying to recruit me or recruit through me - the vast majority of the time it's a pair of non-technical co-founders looking to third founder aboard, a technical cofounder, to build the MVP prior to raising some money. In my personal experience, the majority of pitches I've received have been poorly calculated and in need of much improvement.

Speaking as a former and future technical founder, I wanted to share my perspective on what non-technical (and technical, for that matter) founders could do differently to try to bring an early tech guy / gal onboard.

Don't Pitch Airtight Ideas; Start a Conversation

The last pitch most technical people entrepreneurial enough to leave a well-compensated job for a startup with no income want hear is one where a product-oriented founder presents an airtight idea that has no room for discussion whatsoever; every single pixel and user interaction has been planned, as has the business model and everything else. They just need a code monkey to build it.

If this sounds like you, start over or hire an outsourcing firm. Founders want to leave their mark on the the business itself and that means all aspects of it, whether it's the branding, the commercial model, or the product's implementation. Sure, a technical co-founder will defer to a commerce person on the specifics of the customer acquisition strategy or the product person on the details of the UX, but that doesn't mean that they want to sit out of those conversations in their entirety.

Any technical co-founder who's willing to take the risk to leave a high-paying job where they do someone else's bidding isn't going to take a not-yet-paying job to do someone else's bidding. They want intellectual co-ownership as much as any of the other founders.

A better way to do this is to start a conversation about a business idea in general, get the people you want as technical co-founders to buy-in and contribute their own ideas into the business, and let them take some degree of intellectual ownership over the project. Don't pitch! Ask questions - get the people you want to co-found with you involved. The amount of work someone like me will do without cashmoney for a project that we "co-own" is dramatically higher than if we were working on "someone else's project" under the same conditions. Read Leadership is an Art and remember what Max Depree says about letting your creative giants roam free; that applies here!

If you're not comfortable letting a geek (or anyone other than yourself) into the idea ownership fold, you're probably not mature enough to found a company.

Build a Demo Yourself

You know what impresses the hell out of me? When a non-technical person has the drive to build an early prototype or a set of wireframes themselves to help illustrate the concept and what they ultimately want to do.

There's still room in the business model and product idea for me to get some mindshare (see point #1,) but the fact that the person was passionate and humble enough to build a cludgy demo that doesn't work quite right tells me that they're not going to flake out and move onto something else while I'm left holding the bag.

A demo is also a great way to get a tech co-founder to buy in, see where improvements can be made, and help them understand the business.

Prove Your Worth

I know I can code, and I can prove it with my Github profile or my portfolio - how do I know that you can aquire customers or design a truly usuable prodct? Go out of your way to demonstrate that you've got skills - get some early partners signed up early; build a blog and a following around whatever idea you have; get some user testominals; do some UX testing; and so forth.

Present an Interesting Challenge

You know what intrigues me, as a developer? Solving big problems and helping a business grow. You know what doesn't? Modifying a WordPress blog for a lame-assed content play. Give me (and other technical types) something big we can chew on - we dig that. It's not that we're looking for overly-complicated solutions for simple problems - we're looking for interesting problems.

Here's how you can tell if your problem is interesting or not: is there an off-the-shelf product that does this? If the answer is "yes," you probably don't need a techincal co-founder.

If you need some advice, swing by Coloft and I'd be happy to talk with you. I'm usually there ;)

If you enjoyed this post, make sure you subscribe to my RSS feed!

I am pleased to announce something very exciting that Microsoft is doing in my neighborhood of Santa Monica, California: we’re putting together XAPFest, a massive Windows Phone 7 hackathon aimed to bring together startups and mobile developers of all skill levels for a day of creativity and competition.

XAPFest is going down on Saturday, June 4th at the Loews Santa Monica Beach Hotel (directions) – doors open at 9:00am and will close at approximately 10:00pm. There will be opportunities for individuals and teams of developers to win prizes, eat great food, and have fun hacking down by the beach.

XAPFest is free to attend, and anyone can register for XAPFest if they wish to participate.

So here’s the full scoop behind XAPFest.

XAPFest Rules & Conditions

Your goal as a XAPFest participant is to produce a Windows Phone 7 application in a 80-90% complete state by 6:00pm on Saturday, June 4^th at the Loews Santa Monica Beach Hotel (see the full schedule and driving directions.)

Here are the rules:

1. You can get started early, and we ENCOURAGE you to get started before June 4^th; install the tools and create a project on XAPFest.com and begin working on your app ASAP.
2. You can work either as an individual or on a team of up the three people.
3. Any apps you submit for consideration must not be in the marketplace prior to June 4^th (new apps only!)
4. In order to claim a prize, your app has to be accepted into the Windows Phone 7 marketplace shortly after XAPFest.
5. You can submit multiple apps in XAPFest, but a team can only claim one prize in total.

Install the free Windows Phone 7 development tools early, create an app project, invite your friends, and write updates / post screenshots for your apps often!

If you have any questions about the event or want to know how to get involved (beyond registering and attending XAPFest,) please contact me and I’ll be in touch!

Otherwise, see you on June 4^th!

P.S. Take a look at the apps I've created for XAPFest:

• Lolcats Professional Pro Plus
• Loldogs Home Ultimate Edition

If you enjoyed this post, make sure you subscribe to my RSS feed!

I wanted to post this the morning after Startup Weekend Los Angeles concluded in late February, but due to the fact that I along with half my team (Minboxed) came down with the flu the following morning, I postponed this for long than I would have liked.

Startup Weekend Los Angeles stands out among other Startup Weekends in that each one of these events have produced real companies like Vol.ly, Foodme, Ming.ly, and Zaarly – who took first place in this very Startup Weekend and recently closed a $1m dollar round of funding and soft-launched at SXSW (great job, guys!)

The quality bar for talent is high and the judges are terrific – this year we were even treated to a surprise visit from Ashton Kutcher and Demi Moore, who judged my presentation along with 9 others.

This marked my third startup weekend, my second as a participant, and my first as a team lead.

I learn something new at each Startup Weekend; the ultimate value in these events isn’t really producing a product or a company – it’s learning how to work alongside a team of strangers to build something that didn’t exist 56 hours prior.

In that vein, I thought I would share what I learned.

1. You don’t need a functional product demo to win Startup Weekend

If I can point to one thing that I personally did wrong in this event, it was over-emphasis on building a functional prototype at the detriment of everything else. I can’t help it – I’m an engineer and a passionate geek.

I spent all of Saturday hammering out a prototype, figuring out how to connect to Gmail, how to use IMAP, how to write SQL queries to score achievements, how to batch everything from an ASP.NET MVC app on AppHarbor without worker roles, and so forth…

Minboxed didn’t place in the top three at the end of the judging, despite solid engineering and design efforts from our team – another startup, Eventify.me won 2nd place however.

In the course of Eventify.me’s demo of their live product, their entire thing came down and the team leader was forced to scramble onstage for the duration of her presentation. It’s the sort of nightmare scenario that every presenter worries about. In the end, it didn’t matter though – the judges were able to appreciate the quality of the idea and the future of the business without having to see it fully in action.

2. Sell the judges on the business, not the product

We were very focused on making Minboxed an awesome product – competitive social gaming built on top of email in order to make it more fun to be productive with your email. We had some innovative monetization strategies (in my opinion) and a good general strategy for acquiring customers; in other words, I think we made a good case for building a healthy business.

However, in our pitch to the judges those aspects of our work received a fraction of the attention that our product demo and our value proposition did. In hindsight, we made a great product pitch at the cost of a great business pitch.

3. Relate your business model to a proven one

In past Startup Weekends I’ve attended, the winners have always been companies who’ve modified a successful business model to either address a new problem or a new market; Zaarly took the Craigslist model and flipped it on its head, making it demand-driven instead of supply-driven. Hinty, the winner from the previous Startup Weekend LA, took a consumer-facing twist on TellMe’s business model.

I don’t want to make it sound like Startup Weekend judges punish innovative business models – it’s just easier to sell them on something that builds on the success of something else. I still can’t think of anybody who’s built a business doing something close to what Minboxed does; maybe that means it’s a bad fit for Startup Weekend or perhaps it means that we simply needed to go further to prove that there was a viable business behind it.

4. Talk to customers early

We did not talk to customers, a huge mistake. We talked to users, people who would be playing the Minboxed game, but not people who would be paying for it.

Had we talked to customers earlier we would have discovered just how far we needed to go in terms of privacy (one of the judges told me later that this was a big part of the reason why we didn’t make it.) In addition to discovering potential issues early and helping teams pivot on their business models and products, early customer commitments and testimonials are one of the best ways to sell judges on the future of your business.

We were focused on users of products, not customers of our business – a big mistake.

5. Do your pitch presentation with someone who isn’t on your team

Small lesson here – there were a number of things we did to make a good case for Minboxed, but we didn’t touch on them with either enough clarity or enough detail to convince the judges. Had we given our presentation to someone who wasn’t on our team before we ever showed it to the judges, we could have heard their “I don’t understand why…” questions and modified it earlier.

At the end of the day, your idea will be judged by how you communicate it as it will be on its own merits, if not more. Your team will take a myopic view of the business if you don’t include feedback from outsiders, thus why this lesson is important.

6. Cap the number of team members and pick people with specific skills

This is one thing that we did really, really well. We had a team of six, which is still a little large, but we made sure that we had the right people on it. Two engineers, one designer, and three marketing / business development folks.

I had to turn away a few people, and I’m glad that I did – when you get too many people, you spend too much time trying to make sure that everyone is included and trying to roll everybody’s work into the final product / presentation. You’re better off being mean on Friday night and saying “no thanks, we’re good” and paring down your team to the bare essentials.

7. Keep the engineering workflow tight

One problem I have yet to find a good solution to is how to manage the engineering workflow for product development at Startup Weekend.

Following my experience from this past Startup Weekend, it’s my new belief that if you have an appropriately tractable idea for Startup Weekend you should have two engineers: a back-end developer who owns 100% of the database + stack and a front-end developer who implements the JavaScript, CSS, and user-experience implementation. The two engineers and the designer (if there is one) need to hammer out on-paper designs for every page with a user interaction, and the back-end developer needs to create a set of dummy controllers for the front-end developer to build against.

I say this because my teammates and I have spent a lot of time trying to merge divergent bottom-up designs on Sunday on two different Startup Weekends, instead continuing to work on the product, and it’s a major productivity-killer.

If you have better ideas on how to do this and what’s worked for you historically, please leave a comment. I don’t have a perfect system for this.

8. As a team lead, your job is to evangelize

The team lead for any Startup Weekend project is usually going to be the person who pitched the idea before it was selected; as a team lead, your first job is to evangelize a vision to your team from the first second to the last.

If your teammates have a clear vision that they can buy into, it makes it easy for them to self-manage and work with minimal interruption.

Next are your potential customers –evangelize them on the idea and get early commitments and testimonials.

Last are your judges – your job is to evangelize them on the total vision for your team, business, vision, and product and earn their votes.

Stepping away to work on the product and talk to potential customers is still time well-spent, but ultimately your first priority is evangelism.

Thoughts for next time

I’m going to participate in the next Startup Weekend LA, and I’ll pitch a new idea, and even if I don’t win I’ll learn something new. Looking forward to it!

If you enjoyed this post, make sure you subscribe to my RSS feed!

I’ve been working on numerous projects since the year began, and on Sunday night I finally got around to watching The Social Network. My expectation was that the movie was going to be a breathless attempt by Hollywood to insert themselves in something cool and relevant, a tin-eared paean to their own importance. “Hey, we can be part of the social media revolution too – check out this awesome movie we made!”

But I was wrong – the movie was excellent. I assume that aside from some specific numbers regarding equity and valuation that the movie is a pretty accurate depiction of the early years of Facebook. I don’t know Mark, but from the movie I gathered that he was a socially challenged person who was very, very focused on getting one thing done.

What Drives Me

The image that gripped me most from The Social Network was the scene where Mark and the early Facebook engineering team were living together in a small house in Palo Alto, hammering out code and taking ziplines into the swimming pool. I thought “that’s what an adventure looks like – this is what being in a startup should be all about.”

The biggest thing that attracts me to startups is the desire to be a part of a great team and the sense of shared accomplishment and camaraderie that comes along with it. I tried going it fully alone in my last startup because I simply couldn’t wait to find the right teammates any longer, and I just wanted to give it a try. It didn’t work – lesson learned.

I’ve had countless ideas, some of which I’ve tried to implement, but up until I joined Microsoft I was never on a team where everyone really gave a shit and pulled their own weight. My friends in high school and in college talked a lot of game, but no one ever stepped up with me to try to actually accomplish something. So that’s why that particular scene reached me – everyone gave a shit and did the requisite work to prove it.

Not-giving-a-shit is a disease; it corrupts morale and ruins companies. I’ve been in situations where I came into something full of ideas, energy, and effort to match, but was quickly ruined by the malcontent spirits known as don’t-give-a-shitters. If you find yourself surrounded by these types – get out before they spread the infection to you and waste your life.

I’m motivated by working with an effective team of people who want to achieve a common end. I don’t know what truly motivates Mark Zuckerberg, but my best guess is that he’s motivated by the experience of realizing a specific vision for Facebook: to map the college social experience online.

I found the whole experience of watching The Social Network to be deeply motivating - realizing an idea and doing it with the right people is better than all of the wealth in the world, and it's a hell of a lot better than making millions in the stock market. The movie made me want to be a better programmer; take more risks; find more potential teammates; and do it sooner rather than later.

If you enjoyed this post, make sure you subscribe to my RSS feed!

I’ve a lot of friends who are proficient Rails developers, many of whom who have left .NET for Rails.

The one piece of consistent feedback that I hear back from them is that it’s the frictionless Ruby-on-Rails ecosystem that is so attractive; moreso than the Ruby language or the Rails framework itself (although they like that too.)

Heroku, above all others, is hailed as a step forward in developer productivity and easy web application hosting and deployment.

Platform-as-a-Service (PaaS), which is what Heroku provides to Rails developers, is powerful because it eliminates much of the need to manage and maintain infrastructure. Instead of managing a number of virtual machines on a service like EC2, you manage a number of application instances or some other such abstraction. PaaS combined with a continuous build / deployment system is a powerful combination indeed and allows for unparalleled productivity for agile web developers and startups.

.NET developers have had PaaS available to them for a couple of years in the form Windows Azure, but Azure is really meant to service the needs of rapidly growing services and cloud applications, not brand new projects that have no users yet.

AppHarbor fills two needs that are unmet by Azure – it makes it easy (and currently, free) for .NET developers to have access to a Git-enabled continuous development environment, something which our friends on Rails have had for a long time, and it supports the sorts of rapid build / test / deploy workflow that is common among agile groups and startups in particular.

This, in my opinion, makes AppHarbor the perfect starting place in the lifecycle for any new ASP.NET or WCF project.

Here’s how easy it is to get started with AppHarbor using their early beta interface:

Create a new ASP.NET project in Visual Studio

I’m using ASP.NET MVC3 here, which Microsoft just released-to-market yesterday. It’s great if you haven’t used it yet. You can download and install ASP.NET MVC3 here.

Initialize a new Git repository and commit the app

I use Git Extensions for Visual Studio to manage staging / commits, and it also includes the Git bash for Windows. I highly recommend it.

Now you’re all set for your initial deployment on AppHarbor.

Create a new application on AppHarbor

Follow the instructions for adding AppHarbor as a remote to your Git repository

PUSH!

Check the build status on AppHarbor

and then check out the app itself: http://appharbor-demo.apphb.com/ 

If you want to see a more substantial project on AppHarbor, check out Geeky Reads.

That’s all there is to it – it’s a matter of seconds to push and deploy new builds, and thanks to Git’s commit model, it’s effortless to rollback to previous builds. Compare this experience to the pain of doing a traditional web-deploy on a shared host or pushing a solution onto Azure – this is much simpler and faster.

AppHarbor can also hook a unit test project and use the success / fail of those to determine whether or not your build can be deployed, even if it is built successfully.

Want an AppHarbor invite?

If you’re interested in trying out AppHarbor yourself, click here to create a new AppHarbor account courtesy of the special invite code on this link. The AppHarbor team is eager for early adopters and feedback, so by all means please try it out and share your thoughts and experiences with them.

If you enjoyed this post, make sure you subscribe to my RSS feed!

I'm attending DEMO 2010 this week up in (somewhat) sunny Santa Clara, and during the early parts of last night's social media lounge event some members of DEMO's social media team shot a quick interview with me regarding Microsoft's BizSpark program. If you're not familiar with BizSpark then you should watch my interview as it gives a pretty good overview of what the program is about, in my humble opinion :p

If you're interested learning more about Microsoft BizSpark or if you'd like to get involved, you should message me on Twitter or send me an email!

If you enjoyed this post, make sure you subscribe to my RSS feed!

I alluded to a change in my employment circumstances in my previous blog entry, and now that I'm an official Microsoft employee as of Monday I feel extremely comfortable making this information public.

My role is Developer Evangelist for the BizSpark program; Microsoft recruited me for this position after they read .NET Culture Shock: Why .NET Adoption Lags Among Startups and the rest, as they say, is history. I've relocated to the Santa Monica area and my immediate task is to work on increasing goodwill towards Microsoft and the .NET platform among the startups in southern California; it's a prospect that is exciting, daunting, challenging, and mind-blowingly awesome all at once.

If you're involved with startups in SoCal then I will make it my mission to meet you and find a way to help you should you require it. If there's anything I can do to help you, please feel free to contact me.

As for the blog - it's not going to change much :p . If anything, I'm going to have more content as a result and it'll be from a much higher altitude than it was before.

Wohoo!

If you enjoyed this post, make sure you subscribe to my RSS feed!

Today was my last official day at SmartDraw – I’ve worked for this great company for two years and saying all of my goodbyes was bittersweet.

Were it not for the fact that my new employer graciously dropped an irresistible opportunity at my feet¹ I would have been happy putting in another couple of years there and I would have loved to watch it continue to grow into the large company that it will be some day.

You don’t expect to get trophies for leaving a company and moving onto a different job, but oddly enough that’s what literally happened today. My boss took it upon himself to host a happy hour at a local chain restaurant to wish me farewell along with my co-workers. Thirty minutes into the celebration he stood up next to myself and the CEO, gave a quick speech where he rolled off a list of things I had accomplished during my time, and handed me a glass trophy. Good times ensued.

A Culture of Achievement

My next job will plunge me neck-deep into the startup community, although I will not actually be working directly for one. My co-workers know this, so naturally they spent the next hour or so sharing stories with me about the startups they’ve worked for in the past: ProFlowers, Level 3, ADN, and the list goes on.

Not once during the course of these conversations did anybody brag about the money they brought home from the bank as a result of an IPO or an acquisition – what everyone talked about was the thrill of sharing success, of feeling like they’d helped leave some organization in a better shape than they found it.

Everybody who goes to work for a small, young company is an entrepreneur to some extent (the range is debatable, but not in the slightest bit relevant) – you have to be in order to tolerate the risks and lack of security that come with a firm of that size. And why do people do it?

The trophy is just an object and certainly not an ends in and of itself. What it represents, however, is that my peers and co-workers recognize that I left SmartDraw a better place than when I found it. The external validation and praise from my peers is more than welcome too, but it’s not something you can or should expect – SmartDraw just happens to be a truly exceptional place to work with exceptional people.

The reason why people with talent and ambition work for anybody else is this – because we want to be needed as much as we need the job, and we want to have the opportunity to make something better than we found it even if that something wasn’t an idea born of our own imaginations. Creative control doesn’t matter half as much as the knowledge that we can and will make a difference.

For every blog post I read like this one,² where the author basically states that if you recognize your own talent then it’s time for you to become your own boss, I would like to answer it with this:

Being involved with a startup isn’t about a glorious exit, getting rich quick, or being your own boss. It’s about accomplishment, and doing it with a group of people who are really fun to work with. If you start something yourself, then more power to you.

I’m going to work for a great employer, and I couldn’t be happier about it. And one day I’m going to decide to start my own company and I’ll venture off to do that. But ultimately I want the same thing from both opportunities: I want to accomplish things of significance.

If you’re running a company and ever want to attract ambitious people like me, make a case for why you need us, not the other way around.

If you enjoyed this post, make sure you subscribe to my RSS feed!

One of the other things I took away from Code Camp was a bit of .NET culture shock. As you can tell by glimpsing around on this blog, I am somewhat enamored with the idea of starting my own business. I’m a natural entrepreneur and it is my wont to think about startups constantly.

That being said, I’ve always wondered why a platform as widely adopted and supported as .NET isn’t more visible in startup culture. Many major open source  platforms and languages have very visible and vocal presences in the startup community, everything from mainstays like Python and PHP to even the more obscure and specialized ones like Clojure and Hadoop.

.NET on the other hand is conspicuously absent from the startup conversation despite the fact that it is a singularly larger platform than any of the others.

It’s like there’s a silent majority among the development community that just tinkers away on its own projects without even occasionally raising its hands and saying “here’s something clever and unique we did with this platform that no one else has done before.”

It’s somewhat tragic for the .NET community too – because the perceived lack of sex-appeal on the surface doesn’t match the reality of what the platform is capable of.

Just take a brief moment to peruse through CodePlex for more than a couple minutes and you’ll find thousands upon thousands of examples creative open source projects all built in .NET.

And in the startup space there actually are a number of .NET-based startups making it big, including this week’s Hacker News / Social Media darling Woot. But why oh why isn’t there a louder .NET voice in the startup community? Why aren’t there developers from Woot working with developers from StackOverFlow (also implemented in .NET) to encourage more startups to use the extensive .NET stack to create new and exciting products and services?

And most importantly, why aren’t there more startups adopting .NET?

It’s All about the Enterprise

I’ve heard all sorts of lame answers to this question before: “platform lock-in,” “no open standards,” “licensing costs,” and none of them pass the test of objective reality – yes, those are issues that might prevent some developers from adopting .NET in the startup space, but not enough to bar virtually all of them from using .NET, arguably the most comprehensive and versatile platform with the best tools and the best support.¹

At Code Camp I think I finally figured out why this is: it’s the culture of the .NET community itself, not anything specific to the platform or the architecture which supports it.

.NET culture is centered around the concerns of  the enterprise – the large already-established businesses in the economy, not plucky up-and-coming startups. And when I say “culture,” I’m not talking about the development tools – I’m talking about where the hearts and minds of the developers who use the .NET platform are. I’m talking about the blogs and media sources .NET developers read. I’m talking about the networks where .NET developers contribute and the substance of their conversations.

Most of the developers I met developed portals for giant healthcare providers with thousands of employees, worked on legacy code whose lifespan could be measured in decades, worked in teams with hundreds and even thousands of programmers, and lived in ecosystems ruled by large bureaucracies. These are problems to which few if any developers for startups can relate.

That’s why so many of the talks at Code Camp were staked around RAD methodologies for developing internal projects, coding standards, enterprise architecture, and other things that matter to developers who work in giant ecosystems.

And who can blame Microsoft for catering to the enterprise market – that’s where the money is! No one ever became rich selling high-end development tools to a handful of capital-starved, small companies.

However, the consequences of the .NET community’s enterprise-centric culture is that the startup community and the .NET community don’t overlap as much as they do for other technologies.

As a result, developers working for startups and even the startup founders themselves don’t get much exposure to .NET and don’t think of it as an applicable tool for their purposes.

The flipside is that many .NET developers who want to work for hot startups don’t have as many opportunities to do so unless they abandon the platform for a more “startup-friendly” one or start a company themselves.

So what do the members of the .NET community fuss over? They worry about supporting legacy systems, building enterprise architectures which can service multiple departments, they worry about large systems for supporting in-house business processes, and they worry about satisfying the needs of stakeholders throughout their companies.

.NET developers in general, worry about architecture in order to support systems.

Members of the startup community fuss over a very different set of issues – they’re their own stakeholders, they worry about concurrency, they worry about scalability, they worry about user experience design, they worry about supporting multiple clients and browsers, and they worry about how their designs will impact their bottom line.

Startup developers in general, worry about architecture in order to support products.

See the difference? .NET is perfectly capable of fulfilling the needs of product designers and startups, but comparatively little² of the .NET culture, literature, and conversation is product-centric – instead the majority of it is structured around using .NET to support the needs of the business, not building the business’ products itself!

But It Doesn’t Have to Be

One thing that should be clear here is that any platform, not just .NET, can be used as a platform for building enterprise technology and for building new products. The platforms don’t often dictate their use – that’s the work of the people who develop on them.

If Microsoft wants to make a splash in the startup scene with .NET, and I have every reason to believe they do, then they need to do a better job evangelizing .NET’s capacity from a holistic new service / new product / new business perspective and not just for the enterprise.

Enterprise and startups aren’t mutually exclusive – they’re just different stages in the evolution of software, and there’s no reason why the startup community shouldn’t look at .NET as an attractive starting point for a new business.

The next article I’m going to write on this subject will cover why it’s a good idea for Microsoft to have .NET adopted more readily by the startup community.

If you enjoyed this post, make sure you subscribe to my RSS feed!

I wanted to take the time to follow up on some of the additional lessons I learned from my May startup project, some of which I already shared in The Myth of the Single-Person Startup.

This week I decided to indefinitely postpone my startup project, the same project I spent a month of unpaid leave working on sixteen hours a day. The decision wasn't at all painful, and I came away from it feeling oddly successful and much wiser for it. The project taught me a lot of hard-earned lessons, the kind you only learn experientially, and all it cost me was a couple of paychecks - not bad considering that I don't have any obligations outside of paying my rent on the first of the month at this stage in my life.

But back to the point of this article: learning when it's time to walk away from a project. I have no idea how hard it is for other people to dump something into which they've invested a lot of emotional energy, time, and even money, but for me all it took was recognizing the following things:

1. The effort needed to actually implement the project's MVP (minimum viable product) grows explosively even though you're not adding any new features or functionality.

   I suspect that anyone who reads this is going to think "well, why don't you reduce the complexity of your MVP then?" to which I reply "the point of an MVP is that that's as simple as it gets - you can't reduce it." Reducing my initial feature set wasn't an option given the competition in my space as it would forgo requiring my product's differentiation - although I had plans for something much more grandiose down the road, my vision of an MVP was assuredly realistic and modest on paper.

   However, when it came time for implementation I came to appreciate just how complicated some of the mundane details of the project truly were. It wasn't over-engineering, it wasn't poor design, and it wasn't any of the usual suspects - it was that I was unable to realize the full scope of the project's complexity without getting into the guts of it.

2. The competitive space and surrounding ecosystem is changing more rapidly than you can keep pace with.

   My idea (a social media analytics tool for marketers) is in a domain with lots of fast-moving competitors. Although none of the present competitors have built anything that truly captures the value or essence of my idea, they're rolling out innovations and new products at a pace I cannot maintain, and they're better suited than I am to adapt to rapid changes in the surrounding environment, such as Facebook's rapid changes to its APIs.

   I'm a one-man startup trying to compete with well-funded companies in an explosively innovative space - without quitting my day job, finding funding, and building a team, things I'm not suited to do presently, it's a battle that would have been difficult for me to fight.

3. The technical depth of the product goes beyond your technical expertise.

   This is also called "getting in over your head." As you can probably tell by looking around this website, my real world experience in software development is wanting not for lack of intellectual effort mind you. It's largely because I've been out of a computer science program for two years working full-time as a marketer.

   Nevertheless, I'm enthusiastic about getting back into it and I was excited to take on a big project like this. Unfortunately, I learned quickly that an MVP for a startup is a terrible place to catch up on programming techniques and technologies.

It's was really the combination of all three of these that drove me to ultimately shelve the project, rather than any single one. I'm sure with enough ingenuity and effort one could find the resources and methods to overcome at least one of these problems, but all three at once was too daunting for a young solo entrepreneur who was still working full time.

If you enjoyed this post, make sure you subscribe to my RSS feed!