It would be fun to build the fitbit and basis integrations. Also, Randall Munroe offered a different approach: http://xkcd.com/1109/ :)
482 karma · joined May 10, 2012
It would be fun to build the fitbit and basis integrations. Also, Randall Munroe offered a different approach: http://xkcd.com/1109/ :)
Clients see a list of user stories or other deliverables and can discuss, and file issues and bugs against them. Developers can track their own bugs, finer-grained tasks and issues privately. These two sides of the software are linked for the developer, i.e. as a developer I can add detail and break down a client request into smaller stories without exposing the client to the gritty details, and keep track of which client request(s) different issues and stories are related to. Also useful for filing issues the client doesn't need to know about, say, bugs I find before they do :)
The problem this solves is that I have to maintain two issue trackers, one focused on user stories and features (usually a google spreadsheet), and another for more technical tasks and bugs (usually pivotal tracker). I want to keep it all in one place. I would be surprised if this doesn't already exist, but I haven't been able to find it.
Maybe a mobile-only button to expand the sidebar, and then the list of articles takes up the full screen, sliding away after an article is selected?
Most of the work I do is intellectually beneath someone with 30+ years of experience in C, and below their theoretical earning potential, but if the alternative is near poverty it seems like it should be workable.
0) There's a good chance your main obstacles aren't related to server optimization or finding the right mix of features to roll into a product. You probably need to clarify your assumptions and make sure there's really a business to be had.
1) Consider honestly whether it's realistic to serve organizations that can't pay $40 a month for software they need. I'm not saying it's impossible or undesirable, but it's a critical question to answer for yourself. You need to eat, and choosing to work with these organizations means you'll have to have to subsidize your time with other, higher paying work, offer a level of service that won't satisfy you or your customers, or both.
It's possible there's a large enough number of customers that you could support a business on < $40/month, but it's unlikely for non-profits, especially given your experience with their heterogeneous needs.
2) In light of their reluctance to spend, how sure are you that you've identified a critical need for these organizations? This isn't necessarily an indictment of your product. In my experience many small NGOs are still figuring out their internal processes, and what's important to them and their funders. Codifying nascent processes in software is hard - bordering on impossible - and sales cycles can be untenably long. On the plus side it means they're often willing to be flexible and work with you as you figure out what the software should do.
3) If you do move forward (and of course you probably will), be creative about funding. Working with non-profit arts organizations gives you a great story to tell. If submission management and evaluation really is critical, can you work with your customers to incorporate a software budget into their funding proposals? Find out who the funders are. What are their priorities? Can you appeal directly to funders and show them how your software can help achieve and monitor their objectives, and communicate their impact more effectively?
I'd love to hear what you end up doing. Feel free to reach out (my username at gmail) if I can help.
What does the tech stack look like? Is it open source?
In the post I saw the author suggested that good people/companies will open up and tell you what's not working, and bad ones will lie and say everything's great.
If someone's not excited about the actual process of learning to code, a)they'll probably get discouraged quickly and b)there's probably a more efficient way for them to get a prototype of their app than learning to code from scratch.
It's fantastic to see Sue and M-Farm getting this kind of exposure.
I've talked to several professional devs in the process. The best ask thought provoking questions about my technology choices and business plan, even if they're not available -- one even took an afternoon to work on a prototype Android client with me. I appreciate the frustration that motivates the original post, but a polite no is usually enough to deflect inquiries that aren't serious or well thought out, and an angry blog about "business guys" risks turning off quality people.