How we rewrote the Kicksend web app in one month: tips & tricks
In this technical retrospective (2012), @skyfallsin shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Web 2.0 Genesis (2007–2013)
COMMUNITY SCORE 67 points
TOTAL DISCUSSIONS 9 comments
Friendly tip. Add a really obvious link to your product on the blog somewhere. Also the kicksend logo should probably not link back to blog.kicksend.com, that's really irritating, why would I ever want to go to the root of your blog?
It's a conversion barrier to have to transfer to the address bar to figure out who the hell you are.
After all what's the point in this traffic if you can't capitalize on it.
Rewrites can either be awesome or a struggle to complete and release. Looks like you guys did well. How did you run alternate code in parallel in production - I'm concerned about breaking SEO.
Things you should never do, part 1: http://www.joelonsoftware.com/articles/fog0000000069.html ↗
nice job on the rewrite!
similar concept: http://boxify.me ↗
built in 1 morning by 1 person. disclaimer: it was me.
If switching over involved flipping a switch then you were doing some type of staging. I had the initial impression that you were deploying live.