TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Small company developer pain points

5 点作者 ph33t超过 9 年前
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.

4 条评论

saluki超过 9 年前
It&#x27;s always tough balancing features and staying out of the trap of adding features that don&#x27;t provide a lot of value to your users but takes up a lot of development time.<p>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&#x2F;cost should be considered when mapping out features.<p>Your three items you mentioned (I know you&#x27;re not asking for solutions but here are some thoughts):<p>1. some apps need a calendar . . . try to keep things simple where it provides value but doesn&#x27;t try to clone more robust calendars&#x2F;features by large teams.<p>2. If this is to help clients get in to your app it&#x27;s probably worth it. At the end though you&#x27;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.<p>3. For emails mandrill.com (and similar) have this solved so integrate that in to your app.<p>As long as your work is interesting and you guys are profitable, your job is secure don&#x27;t get to bogged down in what you&#x27;re working on. Maybe build the best calendar integration ever = ). But you can use your knowledge&#x2F;experience to try to improve your app by trying to drive development toward big value&#x2F;low dev cost items.<p>Good luck.
douche超过 9 年前
Integrations with ticketing&#x2F;CRM systems. You can hit the high notes, and go for the handful of most common ones, but it&#x27;s always a temptation to chase a deal and promise another one. Pretty soon, you&#x27;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&#x27;ve got to keep those environments up, and seeded with test data. Some of them are cloud-based, and you can get a free&#x2F;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超过 9 年前
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&#x27;t really blame them, it is typically the only app they know. An MS promotes Office as a &quot;universal&quot; solution for SMEs.<p>Whilst I can&#x27;t eliminate the pain, I found two strategies that work well:<p>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).<p>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).
评论 #11164738 未加载
hanniabu超过 9 年前
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.<p>I&#x27;ve never had a problem with 3a, but I was curious how you went about solving it. Is there an API for that?