Custom software - What are you getting yourself in to?
Custom built software can be fantastic. But you'd better be sure you want it. Like REALLY want it.
I write custom software, and I really feel for some of my customers who didn't know what they were getting themselves in to.
It's not all bad. Really. It's just not all good either.
Of course, it's our job as developers / software consultants / analysts or whatever we are called, to make this process smooth, and make it understood. It's just - well, during the sales process - we kind of want you to buy our services, so we might, just a little bit, gloss over some of the hardships you are in for. Just a little.
The Good
Workflow: Custom software, properly specified and built with agility, can perfectly match your existing workflow. If your workflow is something you have carefully developed, and it isn't a perfect match for, say, Salesforce, Jira etc, then custom may be a better solution.
Compatibility: If all you need is the office suite, windows, sharepoint, exchange and AD, you will find a harmonious bliss of interoperability. Add Xero for accounts and... less so. Instead, you could pay someone who isn't particularly vested in 'stickyness' to a product set to build you new tools which work with your old tools.
(Two whole points, I'm really up for the positives today!)
The Bad
Money: It is going to cost you more. Probably. Maybe not at first, but, probably. Your user-base is what, 5 people?, 50?, 500? It's still a lot smaller than, say, Sharepoint. It's offset by not having as much of what you might call 'bloat', functions you don't require, but the offset usually doesn't quite cover the custom overhead.
Developers: Unless you are a huge enterprise and have the cash to hire another huge enterprise to build your thing, you might have to deal with developers. And we are horrible to deal with. Sorry.
Agile Testing: Do you really have a team large enough and dedicated enough to test the software before it is in production? Hopefully the developer is testing as well, but I mean user acceptance testing. Does this work for you, for your staff? Are you going to know before it's in production, and you are relying on it?
From experience: Probably not. They'll probably give it a cursory glance, then complain that it should have done something which - well, they are right, it should have - but no one actually twigged to that until right now. At end-of-month invoicing time.
Consultation Costs in Staff Time: To get the best software, pre-planning is pretty important. Even with 'agile'.
In a large enterprise, the users of the system are probably represented by a management team who can write and recite their staff workflows. In an SME, you might find that most roles are handled by only one or two people, and every role is pretty unique. That means, to get the software workflow planned, your developer will have to talk to EVERY STAFF MEMBER. That's expensive.
It's going to break: That end-of-month hotfix to add the feature no one really knew was required is going to break something. Most of the time, a testing or rollback strategy will catch it before it's a problem, but if you choose a small dev firm, something is going to fall through. Can you afford the system being down for 4 hours?
Ongoing updates: If you use word, you can update word. If you use Xero, it will update for you, if you custom build software, you have to custom build updates.
-=-=-=-=-=-=-=-=-=-
If you know the bad bits, and go in prepared, custom software is an amazing experience.
If you don't, or you ignore them, it'll hurt.