Half Engineer / Half Business Guy

Starting Your Business And Becoming An Entrepreneur

Tag: Website

You Need A Technical Co-Founder


If you’re starting a tech company, you need a technical co-founder.

Without one, you won’t be able to build your company. In addition, you won’t be able to raise money, because investors know how important it is to have a technical founder on the team.

There are a long list of reasons, but here I’ll make like an entrepreneur and show you the problem, then give you the solution.

Let me start by addressing the most common issues, usually preceded by:

“Sure I can start a tech company without a tech co-founder, I’ll outsource!”


While outsourcing a website is possible, the incentives of whoever you’re sending work to is often the opposite of what you want.

Even for the most expensive contractors, their incentives are:

  • Do the least work possible while getting paid
  • Take longer than you want, if it means they can get paid more

Even a great provider has these incentives – they’ll just act on them differently. The best folks do work quickly to earn repeat business, and don’t charge for hours above their estimate. However, until you’ve had experience with someone, it’s hard to know how they’ll treat a job.

At Catapulter, while some of our contractors worked hard to earn repeat business, others did a quick, messy job and then demanded further hourly payments for edits. To be fair, that’s the lowest of the low, but it absolutely happens, particularly when you’re paying bottom of the barrel prices (common for early, low-cash startups).

(See my post on not getting screwed by outsourcing)


Above, I said that some of our contractors did a bad job. If we didn’t have technical co-founders, we wouldn’t even know it!

Fortunately for us, these were quick jobs, and we could afford to lose the $100 we paid. What if we had gone the outsourced route with a 3-month, several thousand dollar job, with no one to look over our contractors’ shoulders? It would have been a tough spot.

The reality is: you need a technical co-founder you trust. Someone who is not trying to make money from you, and wants your company to succeed.

Your Technical Co-Founder Will:

  • Screen and manage
  • Integrate
  • Do it the right way
  • …and, surprise – code!

Screen and Manage

If you’re non-technical, it’s very difficult to manage technical contractors because you don’t know what they’re doing, or how they need to interact with other contractors. Your technical co-founder will understand how the pieces fit together, and make sure that different components can actually integrate.

Also, you shouldn’t expect every contractor or even employee to be able to problem solve or think pro-actively. You’ll need to give guidance and feedback constantly, and if you’re not technical, you won’t be able to do this correctly by yourself.


If you outsource components, they’ll have to be integrated. Integration takes an immense amount of time, and it’s not something that can be tacked-on to the end of a job. You’ll want someone internal to guide this process (if not do it completely), to make sure it’s done right.

Do It Right

As I mentioned earlier, a contractor is interested in completing the job, and maybe getting repeat business, not making your site as elegant and easy to maintain as possible. Your technical co-founder will want to drive this process, to make sure your site is being built in a scalable, updatable, low maintenance way.


Building a website is not easy. There are many moving parts, and there’s always something that needs to be fixed, changed or updated. You want someone on your team who you can count on for emergency fixes, to fill in the gaps between contractors, or add that one last little feature before the next release.


If you fully outsource your website, the folks building the website are doing it for a paycheck. If you stop paying the bills, they’ll stop building the site.

If you’re a new startup, you’re probably not loaded with cash. You want to find someone who’s going to stick it out with you when the going gets tough, and continue to move forward if you hit a rough patch.

When Should You Start UI/UX Testing? (Very, Very Early.)


Very early in the life of catapulter.com, before we hired a designer, our team drew up a basic user interface that we believed would work well for the site. We haggled over details for a few nights, and finally came up with a pretty solid UI.

Fortunately for us, one of our mentors set time for us to chat with a UI/UX expert before we hired one.

The first thing he asked us was: “how many people did you test with?”

Of course, we had asked a few people what they thought, but we hadn’t put together a preset, regimented UI/UX test. We had intended to have a designer with UI experience take our initial PowerPoint mockups and move to this step.



It turns out, we didn’t have to go to that level. As a professional UI/UX guru, one of our mentor’s typical first steps is to hold very rough UI/UX tests:

  1. Sketch out a rough wireframe of your site, with every piece needed for the user to complete your target action
  2. Write up a questionnaire to be used consistently across users
  3. Find a bunch of people in your target audience who have no idea what the site is about
  4. Ask them to “use” the wireframe as if it were a website – e.g. for us “plan a trip”

Admittedly, we weren’t entirely convinced this would be useful, with such a simple sketch of our idea…but once we started, we quickly realized that the important part was NOT having users visualize the site.

The important part was that users knew what information they wanted next, and they expected that to be available. Just like on a live website, if the required info isn’t readily available, the user will get confused, frustrated, and/or leave your site altogether.

Given this, much of the value in the test was not asking the user “what do you like/dislike”, but watching the user navigate, asking what they’re thinking at each step of the process, and recording as much information about their experience as possible.

One of the best pieces of advice that we received during our intial design phase was from fellow Betaspringer Andrew Draper of Manpacks:

“At every step of the way, get it in front of users as soon as possible. You think you know the main issues with your site, but as soon as you show users, you’re going to get bombarded by complaints, and see that the biggest issues are actually three things you never even thought about.”

GET it “on paper”

Our next step was throwing together a PowerPoint of the site. I admit that this is mostly because I’m an ex-consultant, but one of its best features is that you can create working links between pages, convert to a PDF, and send this linked mock-up of your website by email to users. If you don’t like PowerPoint, there are a ton of other mockup and wireframing options. Ones that I’ve played with include:

  • Cacoo – An online mockup tool that can be used collaboratively like a wiki
  • MockApp – A package of images of iPhone buttons for Photoshop or PPT that can be easily cut/pasted to create a realistic iPhone mockup (Hint: Use this in PowerPoint, print to PDF, and download the $0.99 GoodReader app to use with working links)
  • There are many other, likely better mockup tools that I haven’t worked with – A recent, pretty comprehensive list of other mockup tools can be found here

As you go through the UI/UX tests, as Andrew said, you’ll notice there are a lot of things that need to be changed, many of which you haven’t thought of. At this point, you’ll begin to realize another very important rule of UI/UX design: you’re never done!

The biggest misconception many first-time web designers have is that “we’ll design and build the thing, then we’re done.” Never. You’ll always have something that doesn’t work just right, new features that a ton of users want (expect, really), and you’ll need to continue to iterate.

Therefore, the key takeaway is: don’t half-ass this initial mockup, testing and design phase.

Test with good amount of users (10-20), incorporating their feedback and iterating as you go. Once you’ve begun to understand what your users want, not just what your team thinks they want, you can move on to spending your time and money on building the site.

This way, you’ll start from a much stronger, user-validated initial design, you’ll understand what additional functionality users want you to build, and you’ll have already seen (and hopefully circumvented) many of the pitfalls that can make a user leave your site immediately and never come back.

Using Outsourcing To Build Your Website

I’ve been asked a lot lately about my experience outsourcing web development, so I thought I’d share my experience. At this point, we’ve worked with just under 10 contractors, both designers and coders, to assist our two-person development team.

To be clear, I have only limited experience in programming (I was an engineer with some coding experience, not a web guy). The core functionality of our site was built by our CTO and Algorithm Developer, while we outsourced 1) the front-end design and build, 2) several other bolt-on programs that could be incorporated later to our site.

If you’re building a web business, one of your founders must be technical to understand and manage your contractors – you shouldn’t be outsourcing your entire website.

However, contractors can be an efficient way to get your site up and running more quickly or “rent” expertise (graphic design, iPad development, etc.), though you may have limited resources.

POPULAR Outsourcing Websites

Typical websites people use to quickly find contractors include:

  1. Find hourly/project workers: oDesk , eLance , Freelancer, Rent-A-Coder/vWorker
  2. Post a design project and have contractors submit work to win your payment: 99Designs , Crowdspring
  3. Turn designs into code (HTML/CSS): Psd2html, HTMLBurger

I’ve used oDesk and Freelancer to find hourly workers, 99Designs for design and HTMLBurger for coding.


Beware especially of high-ratings / low # of jobs – Ratings are often pretty worthless. Many of the highly-rated people you’ll find on oDesk are salespeople with coders behind them. They’ll promise anything, give the job to a coder who may not have any expertise in that area, and manage feedback so that they always have a near five-star rating. Once they screw up, they’ll create a new username.

Individuals vs. Organizations – However, there are many successful organizations (i.e. salespeople plus coders) on oDesk, with tens of thousands of hours and great user comments. I haven’t yet been successful with an organization – in large part because of the problem above, and also significant communications lag going through a middleman (the salesperson) who’s often also working as a translator. If you find someone whose username is XYZ but answers emails with name ABC, red flag!

If it’s too good to be true, it usually is – If someone says they can do *anything* for $3/hr, your hunch that it’s not possible is probably correct. The best freelancers I’ve used tell you that they’re amazing at certain things and not as amazing at other things.

Country – I won’t elaborate too much on this here, since I’ve had limited experience and can’t really make a good assessment. However, I’ve heard pretty common threads about particular areas of the world that produce really high-quality work, and others that are quite poor. I’ve had good price-to-quality experience and have heard very good things about Eastern Europe and the Philippines.

To Find the Right Provider – 1) Interview and 2) do a test job! – Giving all the work and large payments up front is often a waste of your time. Make sure you interview well, and then test the applicant’s relevant skills with a test job. Once they succeed, continue to give small pieces at a time. If they push you to give bigger chunks of work, you shouldn’t work with them.


My team hasn’t used hourly payment with contractors, because it gives them an incentive to work slowly, rather than get the job done by a deadline or risk not getting paid. As a result, we’ve only used Fixed Price jobs (this is an option when posting your job on sites like oDesk and Freelancer).

Find out what market price is – On my first job, I said, “if it can’t be done for $500, I don’t want it done, and no one will apply so that’s ok”. Looking back, this was pretty stupid. In fact, the worst developers ended up applying, and they all either quit or tried to raise the price mid-job. The correct way to do this is to search through current listings on the site you’re using (or similar) to understand the market value of a given job and the time it will take.

Also, be careful about milestones – If you set up a milestone payment, one tactic I’ve seen is that contractors try to 2x-3x the remaining price to finish the job. Then they threaten to give you low employer ratings via external email, hurting your chances of hiring top contractors in the future. Customer service won’t help, so make sure you have some reason to trust the coder you’re working with.

Getting Designs from 99Designs

On sites like 99Designs, you post a job description, price and duration, and people will bid with actual work – As before, you should check out the market price for the type of job to make sure you get what you want (e.g. bidding just $300 for a webpage will get you very few entries, though we bid just above that and were lucky enough to find two designs we loved).

You have to put up your money and fees ahead of time, but if you don’t like any of your options, you get your money back…of course, you have to ask a few times as customer service tries to give you various discounts and extensions, but in our experience, you get your refund.

Getting your Designs into Code

99Designs will give you PSDs, You will need to get it into code – One of the quickest / easiest ways to do this in an outsourced way is to give your PSDs (or sometimes even PDFs) to a company that can “slice” PSDs into HTML/CSS. There are a lot of companies that do this, including my personal favorite, HTMLBurger. Keep in mind, this will only be a clickable, pretty shell of a website. You’ll need someone else to make it actually do something.

Make sure you’re very clear on what needs to be separate and dynamic – Your PSD needs to be created such that every picture and every piece of text you want to be separate is created separately, and you specify to the Slicer you want them to act separately. For example, giving a poorly created PSD of Kayak.com to a slicer would yield a website where all the results are lumped together into one big picture, and you can’t change the text.

Hopefully, this was somewhat helpful. It would have been to me!