A unified platform for product teams to announce updates, maintain a changelog, share roadmaps, provide help documentation and collect feedback with the help of AI.
My goal is to help product teams tell users about new features (so they actually use them), gather meaningful feedback (so they build the right things), share plans (so users know what's coming), and provide help (so users don't get stuck).
Doing it as an indie hacker + solo founder + lean. Started 13 days ago. Posting about my journey on Youtube every week day https://www.youtube.com/@dave_cheong
It is a bundled payment gateway+merchant. You don't have to get PCI compliant and you don't need a merchant account (no min transaction volumes, fight chargebacks for you etc).
The down side is they only offer hosted payment pages and not suitable for everything... You need a finite set of goods/services you want to sell (eg monthly plans). You can't automate the process if you're building an online store where your customers can upload items for sale (eg AppStore).
I built the site using the PlayFramework (Java). I'd say it is as rad as Rails, Django, Grails etc and for me much more pleasurable to code in. Who says Java is clunky and deprecated?
In the spirit of lean/mvp, I spent last night building a registry of I haves/needs of accommodation, food, services etc for the people Queensland affected by the floods. Still barebones atm (eg no search). Your feedback welcomed.
It's basically a move into cloud service offerings, so that they can move up the vertical chain - build, run and manage.
I thought it was a little strange at first, but it's quite exciting if they can bring simple hosting and scaling to Java apps, in the same way Spring has made enterprise development easy with Java.
Thanks for the great feedback - and great blog entries. I see where you're coming from especially if the guilt makes you avoid working on your startup.
For me, it's not so much as guilt. It's more about a question of focus. How does one consider an open-ended task done? Is it when it is at a quality we are satisfied with?
If my startup has 100 bugs, can I say it is finished? I guess it'll depend on the bugs, priority, importance of these bugs and what type of product it is. Early adopters are probably also more forgiving of using a buggy system, so it's probably ok to ship with known bugs.
The problem with time boxing is we allocate fixed amount of time to work on something, but if the time elapses and the task isn't finished, we're likely to schedule more time at it. The problem is without proper focus (maybe being conscious of some reward or penalty) if we're late, we might continue the blow out.
You're right though, as everyone around us is on our back, we don't need us to get on our own backs too! So perhaps, it isn't a black/white situation, but case-by-case instead.
Agreed to a certain extent. Yes, blindly increasing the pain will limit your possibilities, but appropriate application of it is a good move.
If you're in the planning phase or design phase, you don't want to needlessly time box it and/or punish yourself for failing to meet a deadline, because it will limit what you come up with.
However if you're in the building phase, say all the broad stroke type of decisions have been made and the main task is plain old coding / grunt work, you can use the pain to motivate you from distractions and procrastination.
Thanks for the comment and excellent advice. I like what you said and where you're headed and would love to hear from you or anyone out there on what they are doing to motivate themselves to finish their product/service and get to the launch pad.
All I'm after at the end of the day (I assume others are the same), is to find tools we can use to help improve the chances of our startups succeeding.
Loved to hear from the more experienced folks out there on what keeps them going. My article was only intended to help others by sharing what my present thinking is, but if I'm wrong, I'll be the first to admit it and reshape my mental picture.
Thanks for the great comment and I agree with your point. In fact, I experienced the same myself. There have been weeks where I didn't want to look at the code and subsequently nothing got done. There are other times though I fired up the IDE only to tweaked little things like a CSS style or refactor a simple method, only to find I had built up momentum and got lots of little things done.
This however wasn't the point to the article. The point I was trying to get at (perhaps not well), is the importance of setting a penalty when we didn't make a self-imposed deadline. So instead of just spending 20 mins tweaking a CSS, perhaps my time was better spent on the tasks which would actually contribute to the completion of the task. This focus on the end goal I believe can be a powerful force in helping us finish.
I can attest to that as I am the perpetual tweaker. Everytime I look at a site I'm building, I get more and more tired of its look and feel. So before I finish a project, often I'd have switched styles 10 times! For me, having the penalty clause helps me keep in focus.
Thanks for commenting and you make an excellent point. In fact I wrote a little piece awhile ago about how one can overcome distractions and in it I describe there are essentially two motivating factors: one is pleasure and the other is pain.
The same analogy can be used here. In order to accomplish something important to you (say your startup), you can either increase the pleasure or satisfaction you get when you achieve it, and/or increase the pain associated with failure.
So I take your point about focusing on the negative, but I never claim that "the only motivation that works is negative". In fact I believe both positive/negative and pleasure/pain play important roles as motivators.
Having said all that, don't underestimate the power of the fear of failure/pain/punishment, as it is a major component of the human condition. I disagree that only "mediocre" things can be created out of fear and punishment for failure.
In fact, experienced entrepreneurs will tell you that a "big unstoppable desire to build things" is a terrible thing to build a sustainable business on. Sure, it's great to kick start things, but building a business is 99% hard work. Can you truly build a business on sheer desire alone? What if that desire went away? Ask yourself that question the next time you are up at 3am trying to fix an obscure bug in someone else's code.
Thanks for the great comment! I would love to hear what everyone else thinks also given the diverse background of people here on HN.
Thanks for the follow up. I'll stress again, I'm not implying there are any hard/fast rules as you can see from the comments I've made here. If I have set the wrong impression, my apologies.
We all know here that being an entrepreneur is more like art than science. There is no one true way. Something which worked for someone in one instance may not work for you even if by rationale it makes sense and all the stars are aligned.
A unified platform for product teams to announce updates, maintain a changelog, share roadmaps, provide help documentation and collect feedback with the help of AI.
My goal is to help product teams tell users about new features (so they actually use them), gather meaningful feedback (so they build the right things), share plans (so users know what's coming), and provide help (so users don't get stuck).
Doing it as an indie hacker + solo founder + lean. Started 13 days ago. Posting about my journey on Youtube every week day https://www.youtube.com/@dave_cheong