|
As others have mentioned, if you sell it to them, it's now going to be on you to support the app. You said your fulltime job is in retail, you're not a fulltime developer - if a significant problem is found and they want you to start working on a fix right away, how's that going to work out with your regular job? Also, expect feature creep.
If you want to avoid this sort of situation, sell it to them for a lump sum, as is, including the source and decent build documentation, so if there's a problem, you're not the only resource they can turn to in order to get something fixed. IF they want you to be the one working on fixes/new features, start billing them separately when these things arise.
|
|
|
|
|
I think it's fantastic when a hobbyist uses their skills to solve a real world problem in their current job. I mean, it's one thing to create a spreadsheet, but an app (of course I don't have any idea what it does) that someone is willing to pay you for is something else. Congrats! Now you have some decisions to make. Of course it all depends on the money.
If you have any intentions of making money on this app you need to:
0: form an llc - this protects you from personal liability should something go terribly wrong
1: insure your llc for double protection, specifically errors and omissions
2: keep control of your source code!
3: create a EULA - there are samples all over the place. Find one you like and change the names.
As for what to charge, some money up front should be expected, but imho an annual contract is the way to go...recurring revenue are an incentive for you to maintain and improve the app.
Also be prepared for them to ask for exclusive rights. (hint: this is your leverage in the deal) Good luck!
"Go forth into the source" - Neal Morse
modified 26-Jul-19 13:20pm.
|
|
|
|
|
I would make a version that does almost everything necessary, but not quite, and then let them use it on a trial basis. If they like it and want it then they can buy it from you at a price of your choosing and you can add in the lacking feature(s). You can also set a rate of payment for maintenance and enhancements. If you just give it all to them at one go then they will likely never pay you and will probably want changes to be done for free. You hold all the cards so give nothing away!
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Do some market research. What do similar applications cost?
You need to get paid for your time spent developing that application.
You need to get paid for your time supporting it. Consider a support contract for this part.
You need to get paid a living wage. Don't accept less than you would as a retail employee for the same work, but software developers typically get paid more. Maybe look into the mean compensation for what developers with an equivalent amount of experience get.
Don't sell them the application. Sell them the right to use the application. Make sure you retain rights to sell it to other customers, possibly ones that compete with them, multiplying what you earn for your efforts. Non-competition sales are also done, they cost more, especially if the application would otherwise have value to other customers.
Buying source code to an application usually costs more, so make it clear whether that's included or not (preferably not). If you've already published the source code, take it down now.
Expect that your company is probably expecting to get a bargain on your work. If you can sell it to other companies, you may have to let your employer have it cheap to get your first customer, but then you can charge what it's actually worth to others. This feels wrong, and it feels wrong to be telling you to do this, but you probably won't get a second opportunity like this.
|
|
|
|
|
|
KINK?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
That's a relief because I couldn't justify it: just my brain was goign "K-INK! K-INK!" and I have no idea what it was trying to tell me ...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
echo
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
echo
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
echo
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
echo
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
PING
entia non sunt multiplicanda praeter necessitatem
|
|
|
|
|
|
I figured out an abbreviated way I think, to compute a k value for a given grammar, without computing the k for every rule.
This is important because it makes lookahead computation for a grammar much more realistic in terms of resources used.
Now, I'm not the only one to come up with an optimization to the general LL(k) algorithm. A lot of people have come up with their own. This is part of mine.
What's interesting here is, if it works, and right now I assume it will, then I will have a viable LL(k) parser.
What's more interesting is the math here. I never got taught formally, but so many people with so many optimizations suggests there's an underlying "better way" to compute all this.
And given all the evolution of the subfield since Wirth, it wouldn't surprise me. As math goes, it moves pretty rapidly in terms of advancement. Over the last several decades the math of parsing has gotten more sophisticated and more realistic at the same time, although the underlying problem domain is unchanged.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: I figured out an abbreviated way I think
I first read that as you had figured out an abbreviated way to think!
I'm curious, knowing absolutely nothing about your field but read your posts with interest, is there a mathematical way to prove that algorithm is better? Or, probably more importantly, is actually sound?
|
|
|
|
|
yes, but it's above my paygrade. My education is spotty. I was a homeless teen before landing at microsoft at 18 so I never got a formal education in maths.
There are holes in my knowledge. So I can tell you for sure, that yes there's a mathematical way to prove that it works, and to prove that it's "better" (more efficient) but I couldn't tell you what it was beyond maybe some vague notion.
I'm ordering The Dragon Book right now, and hopefully that will help me with some of the math I need.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
You will want to look into Big O Notation - that should be more helpful for analysis of algorithms than the Dragon Book. Wikipedia's entry should get you started.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
i'm familiarish with it. I'm more interested in the hows. I can glean the complexity from that pretty easily.
The problem I've had learning parsing is my lack of formal computer science and math training.
A lot of course material and lecture notes go over my head sometimes, and while the Dragon Book is no different, it's at least the material all of this stuff cites, so if I need to decode something, it may as well be that.
material like this on the other hand: Translating mathematics into code: Examples in Java, Python, Haskell and Racket[^]
has been immensely helpful and I wish there were more of it. Maybe when i've mastered it some myself I'll write an article here expanding on the subject.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
The Dragon Book is a good start on Compilers, but tends to concentrate on LALR parsers. Nonetheless, much of the material will still be helpful. Good luck.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
hmm. i already do know how to build LALR parsers. I just don't like LR parsing. But I do need to know more about viable prefix computation anyway so the $4.95 was well spent. LOL
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I accidentally got sent an auto termination letter for job abandonment for a job i hadn't heard from since the interview.
yay HR software.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Maybe they think they hired you and forgot to tell you about it.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I called them. It was a glitch. I was like "I abandoned a job? It said I missed 3 scheduled days."
It took them a minute to realize who I was and then apologize for the mix up.
Strange either way. I feel like I just succeeded at failing and it kind of balanced out in the end.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|