Small company developer pain points | Hacker News Reader

Small company developer pain points

5 pointsph33t5 comments

Just curious if anyone who works writing software as a service for a small company (< 10 developers, sys admins, and dba's combined) have particular pain points.

I have a ton of experience in this area, having worked exclusively in this realm for the last 30 years at 4 different companies.

Here are thing software features that send out HUGE red flags to me ... unfortunately they are all asked for over and over again and I have conceded to all of them eventually.

1. Anything to do with building a calendar in the software. People will always want it to be "like outlook" or to do something their existing calendar program does. While this is a lovely thing to want, it is a major endless development pit for a small company with limited resources - the needs of each individual in a calendar/scheduler are so unique and specific. Syncing is another can of worms ...

2. Importing data from Excel spreadsheets. Assuming we can deal with various file versions and read the data, the problems with dates, leading zeroes, commas, formatting and inconsistencies are insane. Excel is great for ad-hoc data manipulation, calculation, and presentation, but for pure data storage and import ... not so much.

3. Sending out bulk emails and ensuring A) them email gets received on the other end without getting spam filtered and B) keeping yourself off of a spam list.

I'm not necessarily looking for solutions or alternatives to the above, just wondering if others feel the same about certain features or see other features in their saas apps as low gain, high resource consumption.

It's always tough balancing features and staying out of the trap of adding features that don't provide a lot of value to your users but takes up a lot of development time.

Maybe you can talk to the rest of the team to try to drive new features toward things that take less development time but provide a lot of value to users. Focus on the large value vs. easier development. But value vs. development time/cost should be considered when mapping out features.

Your three items you mentioned (I know you're not asking for solutions but here are some thoughts):

1. some apps need a calendar . . . try to keep things simple where it provides value but doesn't try to clone more robust calendars/features by large teams.

2. If this is to help clients get in to your app it's probably worth it. At the end though you're talking about storage in xls. If users are manipulating data in xls try to move them over to working with in the app instead and definitely get all the data out of xls and in to the database.

3. For emails mandrill.com (and similar) have this solved so integrate that in to your app.

As long as your work is interesting and you guys are profitable, your job is secure don't get to bogged down in what you're working on. Maybe build the best calendar integration ever = ). But you can use your knowledge/experience to try to improve your app by trying to drive development toward big value/low dev cost items.

Good luck.

Integrations with ticketing/CRM systems. You can hit the high notes, and go for the handful of most common ones, but it's always a temptation to chase a deal and promise another one. Pretty soon, you're spending all your time chasing down things in a half-dozen or more systems, that all have their own idiosyncratic SDKs or APIs, which change at unpredictable rates. Moreover, to do development and testing against those systems, you've got to keep those environments up, and seeded with test data. Some of them are cloud-based, and you can get a free/low cost development instance, but others are big, unwieldy on-premise deployments that require a host of servers to run all their gunk - with costs in server racks, provisioning time, setup time, and non-core expertise in keeping that crap going.

I deal a lot with niche business solutions. In my experience, too many managers and staff think that Excel is the Swiss Army Knife of data management. Can't really blame them, it is typically the only app they know. An MS promotes Office as a "universal" solution for SMEs.

Whilst I can't eliminate the pain, I found two strategies that work well:

1. As far as possible, let them develop spreadsheets and treat them as prototypes. Then take control of the critical ones and polish them so that they work correctly (protect fields, audit calculations, write macros, etc).

2. Instead of importing data from Excel, I export from Excel into a database (designed as a receiver for that data). Then I run a collection of scripts on the database to clean up the data and only then import that cleaned up data into the production database(s).

If you don't mind me asking, what's the going rate for number 1? I've done this for friends for free and would like to freelance in it a bit, but I don't want to be a dick and undercut the industry. Also, how do you go about explaining the value proposition? I know first hand that it's worth it because you're less likely to screw your tables up, it's easier on the eyes, and it takes a less experienced person of you build it a simple interface to interact with. However, management is the one making the call and from experience I know it can be difficult for them to see the value in it especially if they're not the ones using it.

I can confirm number 2 from an internal developer stand point. I really wanted to move our dataset over to a database when I joined, but all those reasons you started made me just slowly back away.

I've never had a problem with 3a, but I was curious how you went about solving it. Is there an API for that?

Reply on news.ycombinator.com