How much is it worth?

Jackal65

Expert Member
Joined
Feb 10, 2024
Messages
2,353
Reaction score
2,546
It is a question I get asked a lot and I have no idea.

My sister wanted to move their business away from a subscription datable that kept tract of inventory mainly. It was easy enough but she wanted other functions like keeping track of sales and quotes and I guess depending who you are and if you are old and slow it took a couple of weeks. Now it is done and it looks good and works well. Who ever posted some of the code on GitHub did a really good job.

My problem now is my brother in law's friend wants the same thing for their business. It is just a lot bigger. So how do I price stuff like this? I am not a developer I am a bloody welder by trade I am old I don't know this stuff.

How much should I charge them? what is a system like this worth? Functions will include basic bookkeeping, keeping track of receipts and inventory management just on a larger scale. I don't know what they are paying right now but my guess is a lot. I don't even know if I can do it but the last couple of projects wasn't horribly hard just frustrating.

1729614472761.png
 
I don't mean to be rude but sounds like a disaster waiting to happen tbh. I don't know how even small companies would consider it as there is just too much risk. Success for all parties is not impossible but it is quite unlikely. The software could do the wrong thing, flat out not ever work or be fraught with bugs that could end the businesses...

With that said personally know of a few one man show non developer home grown software solutions that have seen some success.

Let me try be more helpful.

I pasted your question into ChatGPT:
Pricing a system like this can be tricky, especially when you're not a developer by trade. However, here are a few steps to help guide you through it:

1. **Understand the Scope**: The system for your brother-in-law's friend will be larger, so it’s important to understand exactly what they need. Basic bookkeeping, inventory management, and receipt tracking could vary in complexity depending on their business size and requirements.

2. **Estimate Your Time**: Based on your experience, consider how long it took for the last project and how much more work this bigger system will require. Since you mentioned the last project took a couple of weeks, try to estimate how much additional time a larger scale system might take.

3. **Hourly/Project-Based Pricing**:
- **Hourly**: One approach is to charge by the hour. If you have an idea of how much time you'll spend, decide on a reasonable hourly rate based on your skillset and experience. Even though you're not a professional developer, your time and effort are valuable.
- **Project-Based**: You could also set a flat project fee. This requires estimating your time and adding a buffer for unforeseen complexities.

4. **Market Research**: Find out what similar systems are priced at by professionals or commercial services. This will give you a ballpark idea of what businesses might be willing to pay. You can also compare it to subscription fees they are currently paying.

5. **Consider Maintenance & Updates**: Don’t forget to account for ongoing support or updates they might need after the system is implemented. You can charge a one-time fee or offer a maintenance agreement.

6. **Negotiation**: If you’re unsure about the pricing, consider having a discussion with them to understand their budget and negotiate a price that works for both of you.

For a rough figure: If a developer charges $50-100 per hour, projects like this might range from $5,000 to $20,000 depending on complexity. You might charge less since you’re not a full-time developer, but don't undervalue the effort it will take.

Try it - its a good start.

Please before even thinking about software, start with some analysis and if the companies are serious they should pay you for it. Check out templates for
  • Software Requirement Specification (SRS)
  • Business Requirement Specification (BRS)
  • Functional Requirement Specification (FRS)
They sound like big formal documents but even basic ones will help all parties figure out what is needed. Ask ChatGPT for SRS, BRS and FRS templates for an inventory management system and it will give you a good starting point.
 
Agree with what @Corelli said.

Once your acquaintances know you know how to "code", you suddenly become everyone's best friend because you will build them the next facebook - and generally that ends up with you suddenly having to do EVERYTHING, the research, the use cases, the edge cases, etc, while all they do is send you once a week message, "Hey are you still working on the app??". Loads of lessons learnt in my early 20s.

Unless you also fully understand the domain problem, can identify with the idea and know those who wanted you to build it in the first place brings their meat to the party, I generally would go against it. It's too risky.

That being said, if I were in your shoes, the only way I would be remotely tempted to go all to assist your in-laws's friend's business would be to see their investment up front - meaning, instead of waiting months for you to build it, they essentially hire you, pay you a full time salary - that would replace the welder income - and work with you to build the software that meets their requirements.

And that's when they realise, their current solution, no matter how much they are paying, is still far cheaper than getting someone to build a new one from scratch, unless it's probono - which isn't fair of course.
It's an idea that most non-tech people don't really get.

These things take months to build. There's no point in trying to build it from scratch, for 1 potential business, just to find out they are not interested in using it anymore. The risk shouldn't be all in on you as an individual.


At the same time, as a hacker, it's easy not to want to attempt it because after all, it's fun to start a new project and see it come to life. But then, I'd rather do something solo / indie that I'm truly interested and invested, rather than a boring accounting system for someone else, that you'd probably never use for your own use cases.
 
Last edited:
Agree with what @Corelli said.

Once your acquaintances know you know how to "code", you suddenly become everyone's best friend because you will build them the next facebook - and generally that ends up with you suddenly having to do EVERYTHING, the research, the use cases, the edge cases, etc, while all they do is send you once a week message, "Hey are you still working on the app??". Loads of lessons learnt in my early 20s.

Unless you also fully understand the domain problem, can identify with the idea and know those who wanted you to build it in the first place brings their meat to the party, I generally would go against it. It's too risky.

That being said, if I were in your shoes, the only way I would be remotely tempted to go all to assist your in-laws's friend's business would be to see their investment up front - meaning, instead of waiting months for you to build it, they essentially hire you, pay you a full time salary - that would replace the welder income - and work with you to build the software that meets their requirements.

And that's when they realise, their current solution, no matter how much they are paying, is still far cheaper than getting someone to build a new one from scratch, unless it's probono - which isn't fair of course.
It's an idea that most non-tech people don't really get.

These things take months to build. There's no point in trying to build it from scratch, for 1 potential business, just to find out they are not interested in using it anymore. The risk shouldn't be all in on you as an individual.


At the same time, as a hacker, it's easy not to want to attempt it because after all, it's fun to start a new project and see it come to life. But then, I'd rather do something solo / indie that I'm truly interested and invested, rather than a boring accounting system for someone else, that you'd probably never use for your own use cases.
I will suggest Quickbooks see what they say
 
If you want to do more solo style work, I suggest trying Freelancer.com. I've done a lot of work on there.
As someone that dabbles in programming I did a few good projects. I am not great at it I am not young but I get the job done. I get a lot of little jobs and most times it pays more then changing oil filters and sparkplugs
 
quickbooks or xero are the correct answers

based on the OP, a ballpark is R300-500K - but that's an estimate, not a quotation
 
Features are going to be significantly more than just bookkeeping, receipts, inventory... what about VAT in/out, fixed assets and depreciation, fleet management, payroll... balance sheet, statement of income, surely he does all of that as well?

There are systems out there that do all this stuff already. @waynehooper might have some words of wisdom.
I never seen one application doing absolutely everting without a subscription. How much will such a system cost?
 
Without a subscription? The subscription is there for updates. Systems need updating constantly. There's no such thing as set and forget. That said, I know of one old client of mine running on an NT server based system - they've resorted to running it in a VM to keep it going, but they still have to get data out and do tax calcs and other stuff with it.

It all depends on the scale you're referring to. How big is this operation? Maybe it's not that big?
After talking to the man for a bit I realized what they wanted. Is started out that they just need something like quickbooks. Turns out that part is covered. What they need is management tools. This must keep track of all the stuff that happens inside the workshop. They have web app that cost them a lot of money. I can't believe it cost that much but if its true I can understand why they want to get rid of it.
 
As someone that dabbles in programming I did a few good projects. I am not great at it I am not young but I get the job done. I get a lot of little jobs and most times it pays more then changing oil filters and sparkplugs
Then , to be brutally honest, stay away from trying to develop an accounting system
Edit: said with all respect to you. You will burn your fingers and everybody will be unhappy
 
Last edited:
After talking to the man for a bit I realized what they wanted. Is started out that they just need something like quickbooks. Turns out that part is covered. What they need is management tools. This must keep track of all the stuff that happens inside the workshop. They have web app that cost them a lot of money. I can't believe it cost that much but if its true I can understand why they want to get rid of it.
Ok so that is an operational system. If you can change your processes to fit into one of the standard programs’ feature set then all good. But it’s not always the case. Then you have to go bespoke and integrate, but that is expensive. I always tell people, when they ask me this question, it will cost the same as a car. It depends on what you want but it is roughly in the same ballpark. But I would not tackle such a project if you are not very experienced. You need to understand their domain as well as processes, and then craft a well designed solution. Such a skill set takes a decade to develop.
 
After talking to the man for a bit I realized what they wanted. Is started out that they just need something like quickbooks. Turns out that part is covered. What they need is management tools. This must keep track of all the stuff that happens inside the workshop. They have web app that cost them a lot of money. I can't believe it cost that much but if its true I can understand why they want to get rid of it.
If it costs a lot, there's probably reason for that?
Takes care of constant updates, backups (making sure they don't lose data), infrastructure concerns, security, support, maintenance, etc? It's probably still cheaper vs if they were to do all that themselves, never-mind building software + doing all that themselves?
 
Quickbooks

There you have it

As easy as pie.

It already exists. Dont complicate yourself. You will need maybe like the plus plan.

View attachment 1766942
or Advanced

View attachment 1766943
Technically, you are 100% correct. Sadly it is missing the one feature they want.

A guy you can **** on at all hours cause the thing is not working.

They are simply not willing to pay what is required to scale with the times and demands of their business. That payment is likely not only money, but time for a consultant or studio.

So here we are, a lone ranger hacking code together at 1am for peanuts. And when it breaks, it will cost more, more time, more effort and more frustration and absolutely more money.
 
After talking to the man for a bit I realized what they wanted. Is started out that they just need something like quickbooks. Turns out that part is covered. What they need is management tools. This must keep track of all the stuff that happens inside the workshop. They have web app that cost them a lot of money. I can't believe it cost that much but if its true I can understand why they want to get rid of it.
You're likely seeing $$$ at this point.

You're not ready to earn those, alone, yet, in any reasonable amount of time.

What you don't see is two fold.

1. Workshop management is multi-faceted in its requirements, its stock, part, time, work, worker, client, consumable, deliverable and resource management.

2. Most of this involves a person, a person that has to accurately and timeously fill in a form on a screen.

The solution is staring them in the face... specifically if they have an existing system thats live and integrated.

Pay a person to be responsible for what is happening in their shop, its clearly a management problem, that now "software" has to solve.

You are incapable of building a system that could fulfill their requirements, because no one on earth can.

They need better management, not more code.
 
Agree with what @Corelli said.

Once your acquaintances know you know how to "code", you suddenly become everyone's best friend because you will build them the next facebook - and generally that ends up with you suddenly having to do EVERYTHING, the research, the use cases, the edge cases, etc, while all they do is send you once a week message, "Hey are you still working on the app??". Loads of lessons learnt in my early 20s.

Unless you also fully understand the domain problem, can identify with the idea and know those who wanted you to build it in the first place brings their meat to the party, I generally would go against it. It's too risky.

That being said, if I were in your shoes, the only way I would be remotely tempted to go all to assist your in-laws's friend's business would be to see their investment up front - meaning, instead of waiting months for you to build it, they essentially hire you, pay you a full time salary - that would replace the welder income - and work with you to build the software that meets their requirements.

And that's when they realise, their current solution, no matter how much they are paying, is still far cheaper than getting someone to build a new one from scratch, unless it's probono - which isn't fair of course.
It's an idea that most non-tech people don't really get.

These things take months to build. There's no point in trying to build it from scratch, for 1 potential business, just to find out they are not interested in using it anymore. The risk shouldn't be all in on you as an individual.


At the same time, as a hacker, it's easy not to want to attempt it because after all, it's fun to start a new project and see it come to life. But then, I'd rather do something solo / indie that I'm truly interested and invested, rather than a boring accounting system for someone else, that you'd probably never use for your own use cases.
Ah the joys of software development.

Why we do what we do, is beyond me...

As @Brawler posted above, we don't have 1 iceberg, we have 4

- Functional
- Software
- Business
- Client

And each of those are as deep as they are wide.
 
I built a similar manufacturing ticketing system - granted it was based on their older dos system and found it wasn't too hard to do, but you have to factor in the guarantee period where you fix defects at the very least. The system was still in use years later. Job tickets were written out by hand and captured in hindsight by a clerk to give them inventory updates, billing, etc. I'd personally do it as a cross platform mobile app today.
In DOS? That is punishment compared to the luxury we work in today as far as stack is concerned. You have admirable fortitude, of mind and stomach :laugh:

I agree completely, on both counts.

- Human still required
- A "dumb" mobile app that just fires data at a server is the way to go. The endpoint / data collection device need not be complex.

I raise a beer to your efforts! May there be many more successful projects!
 
Haha, the old system was DOS, mine was Access... this was the 90s before MS SQL became mainstream. Back then it was IBM's db and Oracle systems mostly with a bit of unix / xenix / pick thown in. That said, there was something about being able to punch in data without looking at the screen, trusting that with every press of the enter or tab keys, you knew exactly which field you were entering data into. We used to capture data at the speed of light back then. Windows came along and gave us multitasking, but it sadly also took the trust we had in the position of the cursor. It's actually slowed us down when it comes to raw data capture. Drop-downs, requiring the mouse mean you don't have a second hand on the keyboard - so while you're saving on some keyboard clicks, you're not necessarily faster, having to use a mouse to select the option you want - all while looking at the screen rather than the paper you're capturing from... and while you're using the mouse for drop-downs, you end up using them for radio buttons and checkboxes while you're at it - when you could be using the keyboard...

And we won't even mention the random popups on the screen when a background task fails or is done or whatever... if you're not watching, you're entering data in the wrong place lol.
All true... every word.

I worked in a pharmacy when i was a wee lad, and they went from a unix terminal based ui to a GUI (luckily still debian, if memory serves)

It took nary 2 weeks for every pharmacist to be running a full screen terminal emulation of our old system. Now at slightly higher resolution.

It was that day i came to understand what a "good" ui actually felt like.

Thank you Willie, your memory sparked some good memories of my own.

Have a peaceful day!
 
Top
Sign up to the MyBroadband newsletter
X