What’s the worst part about building apps for your business?

[startupper]

I’ve been researching how small-to-medium sized business build apps. By “build apps”, I mean develop custom, user-facing software for core business processes. By "core", I mean unique and essential to the business, not common. Like, if I were a deli, I wouldn’t try to build a custom food ordering app: I’d get an account on Seamless or Grubhub.


So, assuming no commercial off-the-shelf solutions exist, the four top options for getting a customer-facing or even just employee facing app seem to be:

1. Consulting Agencies / Dev Shops
   
   
2. Hiring Developers as contractors or employees
   
   
3. Doing it yourself.
   
   
4. App Builders
   

The first three seem pretty expensive or difficult. I’ve heard that “App Builders” are supposedly the best mix of “easy” and “productive”, but in my experience, most of them seem “cookie cutter”. Great for content on websites, and not so great when users need to go through complicated, business specific flows.


That said; what is your perspective on building apps for your business? What part of the process is the most aggravating and time-consuming for you?

 

[fisicx]

I'm not at all sure what you are asking. Most people don't build apps for business, it's too expensive and time consuming. If they need something they will get one built. But most don't as just about everything they need is already available.

 

[Ian Sutherland]

Contrary to the last responder there are a lot of good reasons for building your own apps. I worked as an IT Project Manager for many years and a lot of that time was managing projects building bespoke applications; from health & safety compliance to water sampling and testing. Believe me the "off the shelf" applications available are generally over priced and rarely fulfill the needs of the business.
Which brings me on to the main point of my response. The most important part of building any application is the Business Analyst role. Finding out what the business wants from an application, what are the core requirements and what are the nice to haves.
While small and medium businesses may not have the resources to pay for an analyst there's nothing stopping them getting the key stakeholders in a room for a day, writing all their requirements on post it notes and then prioritising. Use the MoSCoW method of Must, Should, Could and Would haves for the requirements.
The biggest lesson I've learned if your building your own app is get the benefits of your investment as soon as possible, don't wait till all the should, could and would haves are built, get the Musts done, start using it, learn some lessons, fix the bugs, but enjoy the benefits. Then if you've budget and motivation left start on the rest.

 

[Ian Sutherland]

Oh, and to answer the last part of the original post. The most frustrating part is the "business" wanting it quicker than you can deliver it, and with more features then they originally asked for alongside the changes they need.
Consider investing in an Agile Scrum training course for the business stakeholders more so than the developers

 

[fisicx]

But Ian, the op was specifically asking about small to medium businesses building their own apps. This doesn't happen. They will employ someone to do it for them. Most small businesses won't have the inhouse skills to develop an app.

The exception would be a company whose equipment requires specialist software but that's not what the op was discussing.

 

[Grimsby]

'App Builders' simply wont work, because unless the app is meaningfully unique you may as well use something that already exists.

This is why most small businesses miss out on the returns.

 

[Ian Sutherland]

But Ian, the op was specifically asking about small to medium businesses building their own apps. This doesn't happen. They will employ someone to do it for them. Most small businesses won't have the inhouse skills to develop an app.

The exception would be a company whose equipment requires specialist software but that's not what the op was discussing.

I agree, most small businesses don't have these resources, but there's nothing stopping them applying the same principles. The business I now work in hosts a lot of MS Access databases developed for or by small businesses as their LOB application. Yes a lot are developed by other small businesses, but some are done in house. Either way they will save money by getting the requirements nailed first.

 

[Grimsby]

Either way they will save money by getting the requirements nailed first.

Something I tell every client from day 1, but often ignored.

It often begins with "We have an idea" and I say "We need a plan".

 

[fisicx]

Much like the 'we want a website' and I ask them: 'what do you want a website for?'. Most people haven't got a clue.

 

[ffox]

I’ve been researching how small-to-medium sized business build apps. By “build apps”, I mean develop custom, user-facing software for core business processes

SharePoint on line as part of the Office 365 suite has all the tools needed for automated workflow, process monitoring and audit. The deployment is largely code free so you don't need apps, or developers to create them. However, -

Which brings me on to the main point of my response. The most important part of building any application is the Business Analyst role. Finding out what the business wants from an application, what are the core requirements and what are the nice to haves.

This is what is lacking in most SMB organisations.

 

[Richard Moore]

My software product was born from an in-house app we built for our small IT company about 15 years ago.

We couldn't find a bit of software to help us manage our jobs and stock, that is not one that wasn't massively complex or massively expensive.

It began as a fairly simple Access database put together by my wife (she's not a coder), and when we outgrew it we migrated it to a Paradox database with a Delphi front end and shortly after that to an MSSQL based system with a .Net front end. I am a developer by trade so it was easy for us to take this step.

In our case it attracted a lot of interest from other businesses so we took the time to develop it into a full blown off the shelf package.

Going back to the original question, the worst part of developing in house software is the lack of development expertise. However using databases such as Access is pretty easy and anyone with a bit of technical skill can put together a bespoke database with a front end that will be "good enough".

Developing apps in house can also be limiting to the business, even if you are a competent developer you may simply not have enough time to create all the features that the business needs - so the business goes wanting while you get the features in place.

A great benefit of developing your own code in house (over getting in a 3rd party to do it) is you can work to your own low standards. Let me qualify that I don't mean that you actually work to low standards, rather that you *can* work to low standards. Business software conforms to the Pareto principle - 80% of the benefit comes from 20% of the code. If you code it yourself for internal use you can do 20% of the code and the business will benefit massively. You can choose to live with errors in the code and get the staff to work around the errors, or you can quickly create front ends without worrying too much about the aesthetics. If you get in a 3rd party, they are going to have to work to a higher standard because they aren't going to be able to (want to) deliver a sub-standard result.

The difference between writing a UI form for internal business use and writing one for production quality is massive. A form that takes you 3 days to write to a reasonable standard for internal use might take 3 weeks to write to production standard.

 

[Stuartb3502]

Actually getting something built after assembling an in-house team is often not that difficult and it can appear to be a very attractive option. More control, no mark-up from a supplier etc etc.

The downsides often come some way down the road. Maybe you hire that smart young person who is able to work wonders with software in nanoseconds and they build exactly what you want. Trying to find someone who has any kind of qualified experience as an engineer is much more difficult.

Why does it matter? Because in-house apps can become incredibly expensive when:-

a) they get baked into your processes, people and other systems
b) they have been built by keen, smart, energetic but inexperienced (often self-taught) folk who do not know how to engineer for long-term supportability
c) knowledge leaves with the keen, smart, energetic slightly more experienced folk who get a better offer now you've helped them build their CVs and you can't offer them a constant diet of exciting new development work.

I'm not trying to argue against ever doing in-house development (I've done and led a lot of it), but I've seen a lot of business managers fall for the allure of getting exactly what they want from someone down the corridor without having a grasp of how IT costs/problems build in the longer term.

It's very easy to find reasons why an off the shelf application is not right for your business ("we're unique in our industry"), but it's often worth changing processes, terminology and training to fit a package solution which has been proven to serve many businesses well already.

Also consider whether that core unique process can often be built around a generic framework application. Unless you're reinventing how an industry works the chances are you're doing a variation of a standard process (e.g. case management, purchase to pay etc).

By the way, do you mean "customer-facing?" rather than "user-facing"?

FWIW I agree whole-heartedly with the sentiments above about the business analyst (product manager if you want to be down with the Agile kids ). Your question talks only about hiring developers but if you do just that you'll spend a lot of money very quickly going in the wrong direction (probability 60%) and at least a good chunk of what they build will be wrong and/or unnecessary (probability 99%).

 

[startupper]

Excellent feedback! Muchos gracias, everyone.

'App Builders' simply wont work, because unless the app is meaningfully unique you may as well use something that already exists.

This is why most small businesses miss out on the returns.

I think a combination of uniqueness and essential-ness of the business function that decides whether or not to build an app. Basically: how many other business besides us perform 'X', and is 'X' essential to our business? 'X' the business function could be essential but every one else has the same function or problem underlying that function-- so invariably there will be a commerical off-the-shelf solution that will target it, that you can just buy and not have to slave over developing. Likewise, if your business function is completely unique, cannot be altered without getting rid of it and starting fresh, but just not that important, e.g., used by three low level employees, then there's no point appifying it.

unique * essential = value of core business function >= cost of developing a custom app

What are your thoughts on this relation? Do you think it fails to consider something important? My gut tells me that business generally want to codify their unique & essential functions, but can't do so because the cost of codifying that core remains too high.

I agree, most small businesses don't have these resources, but there's nothing stopping them applying the same principles. The business I now work in hosts a lot of MS Access databases developed for or by small businesses as their LOB application. Yes a lot are developed by other small businesses, but some are done in house. Either way they will save money by getting the requirements nailed first.

I've heard that MS Access as a LOB application is a poor design choice. What would be just as simple but as effective and more scalable option for small businesses do you think?

SharePoint on line as part of the Office 365 suite has all the tools needed for automated workflow, process monitoring and audit. The deployment is largely code free so you don't need apps, or developers to create them. However, -

This is what is lacking in most SMB organisations.

I'e heard mixed opinions about SharePoint: has it dramatically improved since 2013? Design being considered more important than the actual act of building is a sentiment I wholeheartedly agree with. I suppose the eternal problem is that product design is always behind the requirements or even just the code of an app. Do you know of any builder or software that turns such requirements, or processes-into-flows into apps?

My software product was born from an in-house app we built for our small IT company about 15 years ago.

We couldn't find a bit of software to help us manage our jobs and stock, that is not one that wasn't massively complex or massively expensive.

It began as a fairly simple Access database put together by my wife (she's not a coder), and when we outgrew it we migrated it to a Paradox database with a Delphi front end and shortly after that to an MSSQL based system with a .Net front end. I am a developer by trade so it was easy for us to take this step.

In our case it attracted a lot of interest from other businesses so we took the time to develop it into a full blown off the shelf package.

Going back to the original question, the worst part of developing in house software is the lack of development expertise. However using databases such as Access is pretty easy and anyone with a bit of technical skill can put together a bespoke database with a front end that will be "good enough".

Developing apps in house can also be limiting to the business, even if you are a competent developer you may simply not have enough time to create all the features that the business needs - so the business goes wanting while you get the features in place.

A great benefit of developing your own code in house (over getting in a 3rd party to do it) is you can work to your own low standards. Let me qualify that I don't mean that you actually work to low standards, rather that you *can* work to low standards. Business software conforms to the Pareto principle - 80% of the benefit comes from 20% of the code. If you code it yourself for internal use you can do 20% of the code and the business will benefit massively. You can choose to live with errors in the code and get the staff to work around the errors, or you can quickly create front ends without worrying too much about the aesthetics. If you get in a 3rd party, they are going to have to work to a higher standard because they aren't going to be able to (want to) deliver a sub-standard result.

The difference between writing a UI form for internal business use and writing one for production quality is massive. A form that takes you 3 days to write to a reasonable standard for internal use might take 3 weeks to write to production standard.

I am a developer in my other life and you are absolutely correct about the low standards being easy bars to hit. Most builders out there focus a lot on UI, but when it's internal, UX depends more on completion of the flow.

In your mind, how could access have been made more scalable, so that you could have kept the simplicity but been allowed greater complexity later on?

Actually getting something built after assembling an in-house team is often not that difficult and it can appear to be a very attractive option. More control, no mark-up from a supplier etc etc.

The downsides often come some way down the road. Maybe you hire that smart young person who is able to work wonders with software in nanoseconds and they build exactly what you want. Trying to find someone who has any kind of qualified experience as an engineer is much more difficult.

Why does it matter? Because in-house apps can become incredibly expensive when:-

a) they get baked into your processes, people and other systems
b) they have been built by keen, smart, energetic but inexperienced (often self-taught) folk who do not know how to engineer for long-term supportability
c) knowledge leaves with the keen, smart, energetic slightly more experienced folk who get a better offer now you've helped them build their CVs and you can't offer them a constant diet of exciting new development work.

I'm not trying to argue against ever doing in-house development (I've done and led a lot of it), but I've seen a lot of business managers fall for the allure of getting exactly what they want from someone down the corridor without having a grasp of how IT costs/problems build in the longer term.

It's very easy to find reasons why an off the shelf application is not right for your business ("we're unique in our industry"), but it's often worth changing processes, terminology and training to fit a package solution which has been proven to serve many businesses well already.

Also consider whether that core unique process can often be built around a generic framework application. Unless you're reinventing how an industry works the chances are you're doing a variation of a standard process (e.g. case management, purchase to pay etc).

By the way, do you mean "customer-facing?" rather than "user-facing"?

FWIW I agree whole-heartedly with the sentiments above about the business analyst (product manager if you want to be down with the Agile kids ). Your question talks only about hiring developers but if you do just that you'll spend a lot of money very quickly going in the wrong direction (probability 60%) and at least a good chunk of what they build will be wrong and/or unnecessary (probability 99%).

Indeed, the total cost of ownership for an application is not just the up front development fees, but also the recurring maintenance and later extension/improvement charges. To reduce costs, the app would need to be developed in a way that has a low barrier to understanding and continued development; in a perfect world/the future, this would be a real app builder.

I would say the more unique the business function/process, the harder it is to use existing models defined in other software. And if the function is essential, then I can't imagine a company wanting to make a switch. The relation I posted above might apply here.

Regarding business analyst: I'm surprised that no one has figured out a way yet to turn process into apps. Or rather, emphasize the relations between screens and states of the app, over the UI parts themselves.

 

[ffox]

I'e heard mixed opinions about SharePoint: has it dramatically improved since 2013? Design being considered more important than the actual act of building is a sentiment I wholeheartedly agree with. I suppose the eternal problem is that product design is always behind the requirements or even just the code of an app. Do you know of any builder or software that turns such requirements, or processes-into-flows into apps?

The needs of every business are unique. Sure, there are points of similarity between the needs of business A and those of business B. Software companies take the similarities, create an application and sell the software on the proviso that the user adjusts business practice and process to allow the application to work. SharePoint delivers a platform that the non-technical can use to develop codeless processes to deliver their own unique solutions. The only 'technical' part is the study of the actual business process and the analysis that is required to arrive at an effective solution. In practice SharePoint work flow solutions are simple to create, so a business can trial a range of solutions in order to arrive at a 'best fit' solutions.
The best way to discover the potential of SharePoint is to try it.
I generally create an on-line demonstration of a basic solution to a specific process for my customers so they can see how a solution can be achieved in a real time SharePoint environment. If this is of interest please send me a PM.

 

[garyk]

Why does it matter? Because in-house apps can become incredibly expensive when:-

a) they get baked into your processes, people and other systems
b) they have been built by keen, smart, energetic but inexperienced (often self-taught) folk who do not know how to engineer for long-term supportability
c) knowledge leaves with the keen, smart, energetic slightly more experienced folk who get a better offer now you've helped them build their CVs and you can't offer them a constant diet of exciting new development work.

And d) the solution morphs into a monster but was built on technology to solve a small problem!

Things grow and change over time. I've seen countless examples of word templates and excel spreadsheets being developed as 'solution' which is fine at the start but 3/4 years later and boom this same solution is creaking along and now instead of 1 or 2 people using it its being used by the whole business!

The most extreme example I discovered last year, a company running their whole operation on what must be the largest excel spreadsheet I've ever seen; 59 worksheets, links to around 14/15 other spreadsheets a real monster. Frightening part is this is a £200M+ company!!! Not some little SME.

Of course the other route and quite a popular one is to extend an off the shelf application. That way you get the support of a standard application but just the extended functionality is bespoke. Most accounting/ERP/CRM systems allow for customisation/extending.

 

[Richard Moore]

In your mind, how could access have been made more scalable, so that you could have kept the simplicity but been allowed greater complexity later on?

Our main driver was that we wanted eCommerce capabilities built in from the start. Back then we ran an online computer parts shop (before the likes of eBuyer dominated) and needed to have our stock database sync with our website via ftp. This would have been quite painful to achieve with Access back then (around 2003).

Even if we had separated out the ecommerce software to a separate application, the file based nature of Access didn't really lend itself to being accessed by multiple applications over a network. And writing Access forms to handle things other than data access was quite clunky.

For me though, the main downfall of Access is that because it is often used by non programmers, and Access "apps" tend to be written organically without a proper design. And because Access is quite clunky and constrained to work with the apps tend to quickly spaghettify into an unmaintainable mess. Over the years I've inherited a number of Access databases written by enthusiastic amateurs and in nearly every case it was cheaper and quicker to pull out the data and start again.

So for me, Access applications tends towards ratsh*t over time, whereas a native application (e.g. SQL Server / Winforms or WPF) doesn't (shouldn't ).

 

[garyk]

Agreed @Richard Moore, Access isn't built to scale simple as. But its easy with hindsight to say should have built in <xyz> tool so whilst it gets you from zero to 'something' quickly it isn't a long term solution.

 

[Richard Moore]

Agreed @Richard Moore, Access isn't built to scale simple as. But its easy with hindsight to say should have built in <xyz> tool so whilst it gets you from zero to 'something' quickly it isn't a long term solution.

I think that's the beauty of Access, it allows people with no spare budget (i.e. small startups) and no programming knowledge to build themselves a reasonable level of business automation while they establish their business. It's like a prototype app builder.

When they're ready to move up they can create V2 of their line of business application in whatever package they want. Choosing Access isn't a mistake in this case, just part of the usual evolution of a business infrastructure.

 

[Paul Norman]

I would not personally consider using Access as a serious business application. As stated above, it is just not scalable.

But back to the question.

A business app just might be of value to some businesses. But most are, I suspect, something of an ego trip. Ensure your business system delivers well on a mobile device. But that is not quite the same as an app.

 

[ffox]

I would not personally consider using Access as a serious business application. As stated above, it is just not scalable.

On it's own I would agree, but there are large software vendors such as IDOX and Orchard Housing who deliver industry specific software solutions on large Oracle and Progress database back-ends and recommend use of Access as a means to mine, analyse and report on the data amassed by their software. Microsoft, after years of winding down Access, have now resurrected it as a means of data manipulation for Office 365 SharePoint on-line.
On analysis a good bespoke business app is usually designed to act as a bridge between purchased application software and those in the organisation who don't need full access to the data, but do need access to some of it. Allowing the particular data held in something like Sage to be extracted, transformed and made available to those in the organisation who need it in a rapid and cost effective manner.
You quite rightly make the point that Business systems need to deliver on a mobile device. Through Office 365 and SharePoint on-line data can be imported via Access, transformed and presented on any device (Windows, Android, IoS) that runs an Internet Browser.

 

[startupper]

Our main driver was that we wanted eCommerce capabilities built in from the start. Back then we ran an online computer parts shop (before the likes of eBuyer dominated) and needed to have our stock database sync with our website via ftp. This would have been quite painful to achieve with Access back then (around 2003).

Even if we had separated out the ecommerce software to a separate application, the file based nature of Access didn't really lend itself to being accessed by multiple applications over a network. And writing Access forms to handle things other than data access was quite clunky.

For me though, the main downfall of Access is that because it is often used by non programmers, and Access "apps" tend to be written organically without a proper design. And because Access is quite clunky and constrained to work with the apps tend to quickly spaghettify into an unmaintainable mess. Over the years I've inherited a number of Access databases written by enthusiastic amateurs and in nearly every case it was cheaper and quicker to pull out the data and start again.

So for me, Access applications tends towards ratsh*t over time, whereas a native application (e.g. SQL Server / Winforms or WPF) doesn't (shouldn't ).

Very interesting! Thank you for the feedback

Agreed @Richard Moore, Access isn't built to scale simple as. But its easy with hindsight to say should have built in <xyz> tool so whilst it gets you from zero to 'something' quickly it isn't a long term solution.

Right, there's a graduation problem for most "builder" tools: the simplest builder builds app which are simple, and also low value. You can say the same thing about access: although it's a good place to start, it's not a good place to scale.

I would not personally consider using Access as a serious business application. As stated above, it is just not scalable.

But back to the question.

A business app just might be of value to some businesses. But most are, I suspect, something of an ego trip. Ensure your business system delivers well on a mobile device. But that is not quite the same as an app.

Right, apps can be both web and mobile. The popular connotation is mobile exclusive, but I think that's because most folks use of the web tend to be more browsing than interacting, which is arguably the distinction between apps and webpages.

 

[ffox]

Right, apps can be both web and mobile. The popular connotation is mobile exclusive, but I think that's because most folks use of the web tend to be more browsing than interacting, which is arguably the distinction between apps and webpages.

Not really. We are in the 'cloud' era. Modern solutions can and do deliver functionality that spans web page, interactive web page and app. For full coverage these should be useable on any device, mobile or otherwise. Additionally, the functionality should be OS independent, being accessible on Windows, Android, Linux and MAC.
Apps are never going to replace core business application software. Industry and/or profession specific software will always be used to ensure that business operates within the required legal, moral and ethical frameworks.
Apps act as bridge pieces between data silos stored in business applications, making business critical data available to key users where ever they are on whatever device they use.
Google Apps for business attempts to do this and MS Office 365 does it even better.
As a point of interest O365 delivers cloud MS Access functionality for any device, mobile or otherwise.
As with all software deployment apps need to be developed to a known and documented strategy. That way you don't end up with masses of unconnected software.

 

[MathSpire]

That said; what is your perspective on building apps for your business? What part of the process is the most aggravating and time-consuming for you?

The cross platform difficulty is the most problematic. iOS, Android, Windows. Most people are doing it by coding each separately at huge cost. We are using Xamarin but we'd still rather there were one platform to rule all.

The second problem is databases. You have to have your internal data, the server database, the mobile database, communication to the server database, and communication to the mobile database. One day you will just have your internal data and just "load" and "save" it in a single line of code... but not today.

 

[ffox]

The cross platform difficulty is the most problematic. iOS, Android, Windows

This is not a problem when Office 365 SharePoint on-line is used. All codeless solutions are cross-platform.

The second problem is databases. You have to have your internal data, the server database, the mobile database, communication to the server database, and communication to the mobile database. One day you will just have your internal data and just "load" and "save" it in a single line of code... but not today.

Using Office 365 and MS Access you can link to 99% of all databases and present the content to the user in a SharePoint on-line form for information or live update. Even the most obscure and inaccessible DB can be accessed by dumping relevant data to CSV flat file and linking that to a SharePoint list.

The solutions are largely code free.

 

[nightmare99]

If you are using Office 365 / SharePoint online you now have Power Apps as well which will allow you to build mobile cross platform apps that hook straight in to 365.

 

[The Byre]

It sounds to me that most of you are all shouting about solutions to problems nobody has.

Does the local auto body shop need an app? No.
Does the local sawmill need an app? No.
Does the local hardware shop need an app? No.
Does a factory making pumps and motors need an app? No.

Does anyone need an app? Does a large TV play-out centre need an app? No, they, along with everybody else, have specialist software that covers all their needs. From factories to TV stations, from the nearest corner shop to the bloke selling newspapers, it's all out there already.

 

[ffox]

No, they, along with everybody else, have specialist software that covers all their needs. From factories to TV stations, from the nearest corner shop to the bloke selling newspapers, it's all out there already.

Sure they do. But, what happens when the telephone software, which has all employee names and phone numbers listed, can't share data with the HR system, or any other specialist software system in use. There are two choices. Either go back to the phone system vendor and buy an add-on module (in this scenario I've been quoted figures like 5k), or build an app. The alternative is to maintain data in multiple systems. This leads to inefficiency and increased cost.
I've never come across a business that can't benefit hugely from system interfacing (making systems share data). Most medium and large organisations do this to a degree where interfacing is a whole separate IT industry.
Office 365 delivers the tool set to perform this without the need for coding, allowing the businessman and/or department manager to keep costs down and improve efficiency.

 

[Natalia Bubniuk]

It is quite easy to find a low price freelancer to create a pilot project on your request it does not secure their credibility; the essential complexity lies not just only in finding a craftsman but in building long lasting trustworthy and valuable partnership for the business.

Finding a trustworthy valuable business partner in an outsourcing company, who helps you avoid all of the problems, and is there to rescue you if the project becomes complicated is gold and through working with such you will take full advantage of the outsourcing capabilities.

If you have budget frames it's better to choose The “Moderate” Class Company.
These are the smaller companies with around 10 to 80 people in the office, reasonable spending and streamlined operations. Depending on where in the world they are based, their hourly development rates will fall into the $40-$60 range.

Most commonly such companies are well organized, agile and capable of proceeding faster with the development process without compromising the overall code quality.

 

[Alan]

@Natalia Bubniuk your post is a bit off topic on thread dead for 2 months - not a good way to start on this forum

 

[garyk]

@Natalia Bubniuk your post is a bit off topic on thread dead for 2 months - not a good way to start on this forum

Par for the course on this forum now.

Quality - down

Desperation - up

 

[Natalia Bubniuk]

@garyk @Alan Sorry, maybe I misunderstood the question. Didn't want to spam.

 

[Petr Gogolin]

I think there is also a fifth option for building a web app:

1. Sourcing skilled and experienced analysts for business side and technical side who will do all the necessary groundwork to come up with detailed specs for execution.

2. Hiring your own employee to build and service it.

I understand that many will object to this, since there are some risks involved if you’re not experienced with managing developers. The risks can me diminished by a) detailed and well though-out specs b) regular supervision from contracted senior analyst.

Reason for recommending this combination is that you wrote the app should cover some core areas of your business, therefore I’d say it’s better to have absolute control over the code and immediate capacity for any changes.

 

[The Byre]

Sure they do. But, what happens when the telephone software, which has all employee names and phone numbers listed, can't share data with the HR system, or any other specialist software system in use.

SQL. No open SQL, me no like!