
Small company developer pain points - ph33t
Just curious if anyone who works writing software as a service for a small company (&lt; 10 developers, sys admins, and dba&#x27;s combined) have particular pain points.<p>I have a ton of experience in this area, having worked exclusively in this realm for the last 30 years at 4 different companies.<p>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.<p>1. Anything to do with building a calendar in the software. People will always want it to be &quot;like outlook&quot; 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&#x2F;scheduler are so unique and specific. Syncing is another can of worms ...<p>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.<p>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.<p>I&#x27;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.
======
saluki
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.

------
douche
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.

------
CyberFonic
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).

~~~
hanniabu
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.

------
hanniabu
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?

