Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My company has a client (in the US) that currently offers small businesses web-based payroll software. They want to offer small businesses a web-based accounting package that integrates well with their current web-based offerings. The company does have a CPA on staff which is a bonus. To this point they have said it needs to be a double-entry accounting system, GL, subledger, sales invoicing, cash receipts processing, payables entry and payment processing.

So my question is …

Should we try and write this ourselves from scratch with the on-staff CPA, try the open source path and see if we can adjust it to what we need or is there a different option that I’m not thinking of?

Any advice in any direction would be greatly appreciated.

share|improve this question

closed as off topic by Oded, Glenn Nelson, Yannis, Walter, ChrisF Jan 10 '12 at 23:29

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

How is this on topic here? – Oded Jan 9 '12 at 14:18
How is it not? I can see possibly that its too vague and possibly that is not constructive - but at first glimpse it looks to me like an "is there a gotcha" question. – Murph Jan 9 '12 at 14:29
Sounds like a classic make-or-buy decision, except the question is phrased to be limited to one very concrete decision involving the accounting system at one company. The way it is, I would say, it requires too much specific knowledge of the situation, the company etc. A more general question could be what to consider before starting an in-house (any in-house project), which is the question maple_shaft answered. – PersonalNexus Jan 9 '12 at 16:31

First off, I would be very wary of attempting to write an accounts package from scratch for general use. I can't comment specifically on the US being based in the UK but my experience suggests that accounting is a minefield - its surprisingly complicated (it ought not to be, but it is), has a dense and obscure jargon and the breadth of "minimum capability" is substantial even before you get to your local regulatory requirements.

To be clear, Accountants have the equivalent of hacks to make things balance and your system will have to cope seamlessly...

If it were me I'd probably find one or more existing online accounts systems to partner with and focus on creating a top notch payroll system that integrates really nicely with as many (online) accounts systems as is feasible. Of course it is also the case (in the UK at least) that online accounting is, in many respects, the next big thing... but I'm not sure I'd want to try and get into the game from a standing start now.

share|improve this answer
Two words... Sarbanes Oxley. Enough said. – maple_shaft Jan 9 '12 at 14:39
Good points. If you were to try to build our own Accounting system, it would really be best to have a couple expert accountants on the team to design and execute test cases to cover all the Sccounting business logic. – FrustratedWithFormsDesigner Jan 9 '12 at 15:07
@maple_shaft - They did say "small business" so the nightmare that is SOX compliance wouldn't apply in most cases. – jfrankcarr Jan 9 '12 at 15:46
@jfrankcarr but you paint yourself into a corner by not covering that possibility (both as a user and as a supplier) – Murph Jan 9 '12 at 16:43
@Omnibus, thats the point. It sounds easy, when it isn't. Look at the number of payroll/accounting related gov't projects recently that have gone massively over budget. – Chris Pitman Jan 9 '12 at 17:04

Before considering if taking on an in-house project is a viable option you need to consider the following items:

  • How quickly is the product needed? Do we have the resources available to take on such a product and still meet existing obligations?

  • How much money are they willing to spend for the software? When taking on an internal project, this runs parallel with time, as generally the more time an internal project takes, the more it costs the company in use of company resources to pursue the endeavor.

  • Do you have the necessary domain knowledge available in house to assist in formulating software requirements and needs? Do you have a CPA who can devote the necessary sit down time with you and your team to help the project be a true success? Without this you are just guessing at best.

  • Is the project you are taking on corellated with the line of business your company is currently engaged in? Do they have a software product line that this could be beneficial to or add on to? Does accounting software even remotely relate to what your company does? If not then you have to ask yourself not only are you qualified to do this, SHOULD you be spending time on this or focusing on projects that help move forward the company mission.

share|improve this answer
In addition, I recommend calling it "Cloud Accounting" to make seem like something new. – jfrankcarr Jan 9 '12 at 15:48

If you start to write your own accounting application, the accountant on staff better be able to commmit 110% of her time to this application.

Unless your clients tend to be new companies who are still looking for accounting software, you're better off integrating with what is currently on the market. Maybe there is a market for companies that don't want to use QuickBooks? These decisions get driven by their CPA. Most accountants don't want to learn a new software app.

Start integrating with the top accounting packages their customers are already using or make it easier for them to integrate with their app. The existing customer base would answer this question if you'd just ask them.

share|improve this answer
There is (at least there is here) a certain amount of dissatisfaction with the "market leaders" offerings (from both end users and accountants) so the opportunity does exist - but its a huge investment to bootstrap an accounts package – Murph Jan 9 '12 at 16:43
@Murph My neighbor is an accountant and he gave me the same impression. This isn't because the market leaders necessarily suck though, this could just be because accounting is extremely complicated and everybody has a different way of doing things. Because of this the software targeted to accountants in general is extremely complex and cumbersome to use. What most accountants want is something extremely simple that is tailored to their ways of doing things, and this is usually more custom software. The goals of easy to use and covers everything are exclusive. cont... – maple_shaft Jan 9 '12 at 16:55
... cont, the software is complicated because accounting is complex and varying enough to be justified as its own career. Software to enable accountants to do their job must require a level of sophistication and detailed knowledge such that those writing the software are many orders of magnitude more sophisticated than their users. – maple_shaft Jan 9 '12 at 16:57
@maple_shaft hmm, I respectfully disagree (-: You're not wrong in what you say but I can be adequately certain that in enough cases it is because there are issues with the market leader (in the UK at least) – Murph Jan 9 '12 at 17:04
@Murph Well in a perfect Randian Utopia some lean startup rises up and outcompetes the old stodgy market leaders that rely more on size and politics to dominate the market. But of course since that requires humanity to stop being humanity, that hardly sounds feasible or realistic does it? Size, repuation and politics win supreme again :( – maple_shaft Jan 9 '12 at 17:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.