Half Engineer / Half Business Guy

Starting Your Business And Becoming An Entrepreneur

Tag: Design

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.

More Visuals, Less “UI”

Why don’t more web apps do this?

Today, I saw what I found to be a really sweet bit of UI – the Yelp iPad app. And it got me to thinking, why don’t more “normal” websites do this? Particularly, increase visuals/immersion and stop bombarding me with “features”.

 More Visuals, Less UI

Now that I have most of the core content-websites I use in iOS app form, when I need to, say, book a dinner reservation, look up the hours for the restaurant and check out the menu, I just use my iPhone.

I get all the info I need quickly, with just a few taps of the thumb. And I don’t need to wait for a mess of twitter feeds and ad servers to load up to begin finding content. This would work equally well with a mouse or trackpad.

For me, this Yelp iPad app is perfect. Just the necessary info, with big, satisfying pictures to immerse me in the experience. I wish the web-based Yelp was the same.

Yeah yeah, I know what you’re going to say…

I agree that packing ads on the screen makes a lot of businesses a lot of money, and that users often won’t scroll down the screen or find something hidden behind a button.

However, the successes of iOS and Android suggest that, if designed correctly, simple, great-looking apps with limited feature sets can make users very happy…and still make money.

web apps that keep it simple and look good doing it

 More Visuals, Less UIAnother recent example of a website that just feels good is about.me.

They’ve captured all of the UI they need, and made it beautiful. Any of the bells and whistles they need (peeks at social networking personalities or blog posts) are hidden behind very obvious icons.

When I want to learn about someone, I just want:

  • A brief blurb about who they are
  • A picture / feeling of the person
  • Links to social media personalities
  • Other relevant links

About.me provides all of this info perfectly. (Also, 400K users and a sale to AOL 4 days after launch suggests to me that people are happy with the user interface design.)

Who could use a change

HuffPostWeb 300x258 More Visuals, Less UIThough there are arguments to the contrary, as a user, I would love to see a news site like Huffington Post shift a bit toward its iOS counterpart. Occasionally, I enjoy reading extremely biased political trash, but the websites of The Huffington Post and The Drudge Report just hurt my eyes.

However…the Huffington Post iPhone app is just so easy to use! Very simple, I can flick through stories and categories effortlessly, and all of the features I really need (save, email, search) are neatly hidden away.

huffpost 200x300 More Visuals, Less UI

FOR ME, there is no need for any more real-estate. I understand that research has been done suggesting that “out of sight, out of mind” holds true, and Huffington Post gets more headlines on the screen, raising the chances users will find something they like, etc…

But personally, I would love to see all this beautiful mobile design, whether mobile phone- or tablet-sized, brought into more “standard” web design.

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.