Ask HN: I'm taking 2 weeks off work to build a prototype. Any advice?

17 points by nicwest ↗ HN
As the title says I'm taking 2 weeks off to build a prototype (website + workers) for an idea I have been kicking around friends and family for a few months.

My current plan is to spend the first day planning, 3 days researching, and then 10 days building. (this leaves me 2 days free to watch the rugby and get out and about).

I'm a solo web developer with no dependants, and I'm planning to work from home.

I'm looking for general advice about solo sprint work, personal/time management, and interesting technology.

37 comments

[ 3.5 ms ] story [ 76.4 ms ] thread
I would definitely say commit your timeline to paper/tracking software etc. I do this to myself all the time where I come up with a timeline and don't stick to it. I found that by having it front of my face (like I usually do at work) it helps me stick to it and let my mind wander less.

Also, I have found that at work it is ok if you get sidetracked sometimes because your guilt or sense of responsibility to your coworkers and company will refocus you soon enough. If you are like me, then you have no such thing when working on your own thing. For that reason, I highly recommend keeping regular, well defined work hours. I would even consider one of those apps that won't let you connect to FB, etc. while you work.

As far as technology goes, you can build a solid prototype website in anything these days. Pick the language you know best and also pick a solid foundation. By that I mean do as little as necessary to make the prototype work. Don't fall into the trap of using this as an excuse to try something new (if you want to actually get it done that is). Frameworks are great for this for example.

Good luck!

cheers buddy, I was definitely considering exploring some new stuff, but you are probably right.
Just do yourself a favor and include one more week.

It doesn't matter what kind of project, always include one more week.

Don't be upset if you can't stick to your plan, allow yourself an extra week.

It's not your fault, that's basically software engineerings nature.

You should get out daily, for at least 1 hour. Simply because that one hour is for recharging your brain, which again leads to better performance.

Also what I try to do, when I'm doing a hackathon, is that I'm looking for templates from themeforest or wrapbootstrap.

There are also a lot of good templates for your framework, where auth/register/signup/signin/roles etc. is already done for you.

I don't like reinventing the wheel, I'd rather focus on the business logic.

Ah best laid schemes of mice and men! cheers friend!
>You should get out daily, for at least 1 hour. Simply because that one hour is for recharging your brain, which again leads to better performance.

This has been pivotal for me when I work from home. I like to go out for breakfast to start the day off and then go out again in the afternoon to run some kind of small errand.

For software, create a plan to build what you'd normally code... preferably, something you want. Figure out how to sell it, how long it would take to build (time === money), the business model required including marketing plan to reach profitability, and whatever else you need to launch it. Then build a 10-20 slide deck with a designer about the idea (not a prototype), learn how to present it (don't waste it coding, let others do that in the future) and start pitching at least once or twice during those 2 weeks.

In the end, I hope you'll become a successful technical CEO and great company because you've learned a lot more than an API or two.

Are you being facetious? He wants to build a prototype not hit hype cycle funding.
No not at all, code is especially cheap, almost worthless. He/She already knows how to do that - so don't waste time on something you already know. Focus on:

1. Ensure there is market / product fit

2. How long to get to develop the product

3. Break-even point

Or write a bunch of code, and be left with another if-I-build-it-they-will-come FAIL.

good quality code is not cheap. doing both biz and tech is not mutually exclusive at an early stage
Obviously you need both, that's why I'm suggesting the focus should be on the biz.

I disagree that it's rare or expensive, it's quite the opposite. Most knowledge associated with it has little lifetime value and is constantly tending towards zero - a 5 year old code base that generates little income has a value of near zero or is a liability. You can hire an engineer for a year to build web apps, depending on country, for the price of a medium sized sedan.

that's also true. but at such an early stage it really helps if you do it yourself. you can and should hire later
Be careful not to fall into the notion that you have unlimited time. Don't get obsessed with small details that take too much of your time.

You should work each day like you're going back to the office in 2 days.

Don't build a prototype, build something shitty you're going to sell.

I did that once, a long time ago, and it took me on an amazing adventure.

What did you build out of curiosity?
I agree with the above as well. Take an hour or so really thinking out what you're building, define what your MVP is, build your MVP as your 'prototype' find beta users and get feedback, redefine what you're building if needed (users might want something different then you were planning on making), improve that initial MVP to users standards, ask them what other features they'd like, build those, start charging, continue going through feedback loop again and again.
Something I thought people needed.
Allocate some days to producing wire frames & mockups before development so you know exactly what your building
Have you got any suggestions about wireframing tools? It's not something that I have done a lot of.
Pen and paper works fine...primarily need it just to give you a good idea of what your end product will look like because while you're putting it from mind to paper there is a lot that will usually change and there's a lot you'll realize you'll need to consider once you're actually thinking about everything in enough detail to be able to write it down.

But yeah, pen(or pencil) and paper will be just fine. I'll usually start by writing lightly so when I make mistakes I can just write over it normally and when I make mistakes with that I can go over it a few times to make the lines darker....then after I'll take what I have and redo it real quick on a fresh piece of paper so I have a nice clean copy with no cross outs or write overs.

At work, we use balsamiq but I've also engaged with design firms who produce interactive mock-ups using hotgloo. On the side, I use freemium tools including gliffy. Paper and pen works just fine too, especially when on the go and inspiration hits.
Balsamiq is useful. The company used to, and may still have, a scheme by which, if you have an open source project, you could ask Peldi (the founder) for a free copy. (This was in the early days of the company. I got one that way. Also, it was valid lifelong.)
Scope the entire project into half days worth of work, aim at being in flow for 2-3 hours in each block. (Unless you are not used/trained in being in flow, then the pomodore technique might be better for you)

Lay out the entire 20ish blocks and post them here/email to your friends and family or to some other entrepreneurs that you do not want to dissapoint by not getting stuff done.

Every day, update the post/email with a status, did you get the blocks done and if not why not, what did you learn and what will you do differently tomorrow?

Good luck!

Cool Idea! that structure works pretty nicely for me actually. I'll give it a go thanks pal!
Feel free to email me if you think I can help you in any way!

anders(a)timeblock.com

Build a prototype and then take 2 weeks off. You need those 2 weeks to talk to prospects, see people, and launch.
This.

I thought I needed time off to focus on building Wormhole[1], but actually I'm needing much more time to talk to customers and on-board them. Apart from documentation and lots of feedback to work with.

Now I need the time to work on that feedback, prioritise backlog, keep bringing in users and finally converting some of the users into customers :)

[1]https://wormhole.network

1-Use a to-do list. This might seem like a basic thing, but not many people know how important it is. It allows you to have specific goals everyday that you work toward. Also its very satisfying to checkout a goal :)

2- Work in 25-5 bursts. What that means is that you cut yourself completely from any disturbance, which include your phone, emails, social media, family members... for 25 minutes, that you dedicate completely for work. Then take a 5min rest. Its very effective and something that i do myself.

3-Hire a frontend developer or buy a ready made theme to only focus on the backend stuff. Since UI is very important.

Good luck with your project mate!

If you're planning to make money from it, try doing a good draft of the launch page first. This helps you focus on which features are critical and which are just nice to have that aren't big selling points.

Also, don't obsess about making the code and architecture good. Get it working to prove the idea works then using what you've learned you can go back and improve it. I see so many side projects fail because many coders obsess about making code perfect over more important things. Releasing a project with imperfect code is vastly better to never releasing anything because you procrastinated trying to write perfect code in my opinion.

I like the sentiment here, but don't waste your time on the launch page! You can accomplish the same goal -- determining the crucial features -- by drawing your landing page on paper. List the top three benefits of your app, then list the features absolutely necessary to enable those benefits. That's your MVP.
Build only 1 feature, only 1 page, and make it as appealing as possible before building anything else. Measure the appeal by number of users. Spend the first day launching, however far you get.
you could try using bootstrap studio if it's a web application.
As someone who's going through this process myself, here are some tips:

- Have a clear goal about what you're building. If you don't know where you're headed, you'll end up getting lost.

- Start the research NOW. It takes quite abit of context switching between research and dev. The sooner you get a clear view of how to build it, the better.

- Use tools, frameworks, other people's code, etc. but consider the learning consequences.

- Layout daily goals and your roadmap for all your features. Put it in your calendar

The most successful side project I ever had was an SaaS business I cobbled together in two weeks of Christmas break sophomore year of college. It paid the bills for the rest of college.

This sprint sounds like a great way to force constraint on yourself. Make sure you're using that constraint. Don't work on this like you would any other project. You need to be fully aware of the deadline, and constrain features within it.

If you're making an SaaS, the the first thing you should do is setup payments. That will give you confidence that this sprint can actually result in some real revenue. Then, you can build out the features.

Also, don't experiment with any new technologies. Use only what you know, and prefer shitty spaghetti code over well-architected solutions. Just get this shit out the door.

If the intent is to sell the prototype, put up a landing page right now, with a free Mailchimp subscribe form, and a super simple blog (for extra points, use WordPress, setup Jetpack and Post by Email. Then to "blog" you only have to send an email). Start spreading the word about the product, but also about your two weeks. Dedicate at least a little time each day to update your blog, and/or email your mailing list. People who follow you on the journey will become fans for life.