Financial Software Development Advice

What type of program is this?

Why do you believe you need a custom application?

Are there are no canned packages that will do the function?

Wayne has a great point, it is usually better to buy than to build unless you have a very specific issue that not other company has.

Also, does this new application have to interface with another program such as a General Ledger program? If so, you will probably need to hire a firm that is familiar with the GL package as well.

Here are some general questions/issues to consider:
1. What other program must this new application work with?
2. Is there a buy alternative or alternative that can be purchased then modified for your specific requirements.
3. What computer system are you running and what database software do you currently use?
4. Have you had other applications developed, if so, who did those applications? Sometimes having someone who already knows your company can reduce "educational" costs for a new programmer.
5. Who will maintain the application once it is built? Do you have the internal ability to debug the program? If not, how expensive will it be to maintain once it is built.
6. Look for programming companies that work in your industry. They will more than likely be able to do a more efficient job. They might even have a solution already done.

Too many unanswered questions to be able to give you more help than that.

It would be a program designed to reconcile between two existing platforms on a daily basis and then more extensive during the monthly reconciliation.

We are trying to take a process that takes days and shrink it down to minutes. We've done as much as we can using Macro's but feel like more could be done.

One is a web based program from our carrier and the other is our POS system.

As the owner of a software company, I will tell you how to save money.

First, I'll presume you have evaluated OOB software and found it not useful.

So, let's move on to saving money with custom software.

*1. The more information you have, the more accurate the estimate for the job will be.
1.a. If you enter into negotiations and all you know is, "We do X, and after it figures everything out, Y gets reported." You will be looking at paying a lot of money for the programmer to define the workings in something he/she(I will from now on use "he") has no knowledge of, so he can build a software product you will actually use.
1.b. The more processes you have defined prior to meeting with a software developer, the cheaper it will be, because he will need to spend less time figuring out how things work. The added benefit is that he will be able to deliver the finished product sooner, with fewer bugs. (Most bugs are the result of a process not being properly defined in the analysis phase.)

2. You need to assure your employees that the new software will benefit them, not replace them.
2.a. Along with lack of preparation in defining the process, the second cause of finished product bugs is employees who feel threatened.
2.a.1. An employee who thinks their job is only secure because they have specific knowledge to do a vital job that if they reveal their secret, they will be laid off.
2.a.1.a. What they don't realize is, the harder they fight to keep their secrets, the more it will cost the company when it is found that they are withholding information, the easier it will be to justify getting rid of them...without benefits.
2.b. The employee needs to understand that this new process will make his job easier.

3. Make sure, when you interview software developers that they listen to you.
3.a. When I took a programmer with me to a client, I watched him as well as interacted with the client.
3.a.1. If the programmer started talking programming during that meeting, I took him off the job.
3.a.1.a. In front of the client is when a programmer learns what will make the customer happy.

4. Expect changes
4.a. Chances are, unless you have done it before, several times, you will not be skilled in putting the entire process down on paper.
4.a.1. You are going to realize one thing or another while the developer is in the middle of programming.
4.a.1.a. Depending on when you discover the change, he may need to redo a major portion of it
4.a.1.b. Do not hold back letting the developer know you have changes.
4.a.1.c. The sooner you communicate a change, the cheaper the adjustment will be, and the sooner it will be complete

I am sure there is more to say, but I need to get back.