Writing Android apps, how do I sell it to the client?

[47Ronin]

Was wondering about this, I am still new at development and only have one successful app behind my name that I wrote in python. I sold the app and did not charge for the development time. I actually got a good deal as well. Now this one has an NDA agreement and I doubt I will allow that to happen unless it really is a must.

Now I am on my second build, the client wants me to quote him for the development time per hour? I don't feel this is a good idea because It might take weeks and months. I rather just sell him the app, like I did with a previous client.

Now, obviously I am new at this and don't really know how to deal with this.

How does professionals go about it? Do you charge per hour, or do you rather sell the app once it is complete?

Note on the selling of the app. I do not support the apps I sell. I don't want to end up working for free, so once the software is in use and working, I let the customer sign off on it. Is this a good idea?

What is your take on this?

 

[konfab]

Now I am on my second build, the client wants me to quote him for the development time per hour? I don't feel this is a good idea because It might take weeks and months. I rather just sell him the app, like I did with a previous client.

That is a better deal for you.

How I would go about it is to make sure that you have an agreement about the timeline about what deliverables they want at certain times. As a developer, you do need to be able to have the ability to give a reasonable estimate on how long things will take, and then furthermore keep the client in the loop on your progress.

The reason why it is better is that clients never know what they want, and are almost guaranteed to want to change things. It wouldn't be fair for you to give a fixed cost for the entire process when they can change what they want at any time.

 

[47Ronin]

That is a better deal for you.

How I would go about it is to make sure that you have an agreement about the timeline about what deliverables they want at certain times. As a developer, you do need to be able to have the ability to give a reasonable estimate on how long things will take, and then furthermore keep the client in the loop on your progress.

The reason why it is better is that clients never know what they want, and are almost guaranteed to want to change things. It wouldn't be fair for you to give a fixed cost for the entire process when they can change what they want at any time.

This was very helpful, thank you.

 

[gregmcc]

If you are developing an app for the client, in almost all cases always change for the time it takes to complete it otherwise the goal post will always be moving and client will keep adding things.

Get the client, in writing, to state exactly what is required from the app and you stick to that and quote them on the hours. Once both parties agree you go for it.
If they want to do any major changes on anything then this is a new agreement.

 

[WAslayer]

Charging for the app instead of your time to build the app is never going to be sustainable in the long run..

As others have said, charge per hour, agreement in writing on what exactly client wants, provide reasonable timelines for completion and or major milestones and any big changes to the app would be an amendment to the existing agreement/new one with updated timelines and labour costs..

 

[_kabal_]

Also you need to realize that estimating software build time based on vague “requirements” is a fool’s errand.

It 100% unlikely that you are able to accurately estimate something you have not done.

All our estimates are just that, estimates. The accuracy of these can be refined by doing more up front detailed specifications/requirements analysis - the more detailed the artefacts, the more accurate estimates can be provided.

Here is the hard truth, but don't let it discourage you, use it as motivation, but you need to seriously consider it

• You've built one software application, in Python.
• You know nothing about Kotlin
• You know nothing about Android development
• Given the above points, what you end up building will be a pile of crap, code wise.
• You'll estimate 100 hours, it will take you 500 hours

So you need to consider this in your hourly rate.

 

[rh1]

Just an outsider looking in, not in software, but should I freelance in my field this is how I would go about it.

1. Ask them in writing what they want - clear specifics/everyone must know exactly what being handed over at the end of the job/project
2. Estimate how long it will take if you are 80% productive per item above. (This give leeway for unexpected events) You dont charge for the 20%, you just build it in your timelines.
3. You might reduce or increase your rate. I.e. smaller jobs your rate per hour increase, longer jobs your rate per hour decreases. Why, set up times/admin etc. Small jobs are a PITA, especially if you in a industry that have standards and requirements which need to be adhered to, even for small jobs, hence there is a minimum cost that must be covered. i.e a Two week Job and a four week job for me would R50000 and R60000 respectively just because of the base costs and legal ramifications. A 8 week job might only be R80000. This is if I was working for myself.

 

[konfab]

For OP, do yourself a favour and read up on some software development methodologies.
I would highly recommend reading up on Shape Up, specifically how they say you should write up software specifications.

Shape Up: Stop Running in Circles and Ship Work that Matters

Shape Up will help you break free of “best practices” that aren’t really working, think deeper about the right problems, and start shipping meaningful projects your team can celebrate.

basecamp.com

 

[TStringList]

For OP, do yourself a favour and read up on some software development methodologies.
I would highly recommend reading up on Shape Up, specifically how they say you should write up software specifications.

Shape Up: Stop Running in Circles and Ship Work that Matters

Shape Up will help you break free of “best practices” that aren’t really working, think deeper about the right problems, and start shipping meaningful projects your team can celebrate.

basecamp.com

Chapter 7 - Bets, not Backlogs is really interesting. 6-weeks cycles and no (formal) tracking of issues outside the cycle. Quite different from the usual 2 week cycle with regular Backlog grooming.

 

[_kabal_]

For OP, do yourself a favour and read up on some software development methodologies.
I would highly recommend reading up on Shape Up, specifically how they say you should write up software specifications.

Shape Up: Stop Running in Circles and Ship Work that Matters

Shape Up will help you break free of “best practices” that aren’t really working, think deeper about the right problems, and start shipping meaningful projects your team can celebrate.

basecamp.com

Never seen this. Some really interesting stuff in here. Thanks

 

[Barbarian Conan]

As others have said, regardless of how you charge for it, get the requirements in writing. ALL the requirements. If it's not in writing, you don't do it.
When I just started working, there was an older, ongoing project where the customer apparently said they will don't need to give a spec, they will just review it when it's done and if they are happy they will sign off on it. It dragged on for years.

It depends on how you want to run the project.
Waterfall - If you can get all the requirements up front, you can charge a fixed amount. ANY changes deviating will then be an additional payment from the client. There will be negotiation, questions like "R2K just to add a sort button?????" atc.
Your upfront estimates need to be quite good. Even experienced devs underestimate. Since you are relatively inexperienced, I would say if you are lucky it will take twice as long as you think it will.
Agile - Or you just charge per hour, the customer can make any changes at any time, and you just get paid to do it. For someone relatively inexperienced with requirement elicitation, specs, pitfalls etc this is probably the better option.

 

[Stonemason]

It is also possible to scare off the client with onerous procedures. Ask the client to draw up a spreadsheet with his basic requirement. Usually changes to an existing application will not have more ten 10 or 15 items initially.

You can then do each of the items on the spreadsheet , tick it off and put in your hours next to it. Make sure the spreadsheet is accessible to the client at all times via dropbox or something. He can then see how you are progressing and if you are lucky he will start adding more items to the list.

When you quote, do not give a firm quote, quote on each of the items separately. When you quote you say something like: "This will take me between 2 and 6 hours." Most clients accept that when they are dealing with an individual and not a company.

Good luck. If you play this right you can have the same client for several years and make substantial amounts.

 

[konfab]

Chapter 7 - Bets, not Backlogs is really interesting. 6-weeks cycles and no (formal) tracking of issues outside the cycle. Quite different from the usual 2 week cycle with regular Backlog grooming.

I have been implementing my own version of this for about a year now. (The project I inherited was using it).

Even if you use a completely different agile process, the methodology for writing up specifications for work via pitches is absolutely superior to everything else I have worked with. Strictly shaping requirements based on how much work you can get done in a specific time was a game changer for me.

This is the template I use for writing up all our piece of work.

Problem Statement
=================
The raw idea, a use case, or something we’ve seen that motivates us to work on this

Appetite
========

How much time we want to spend and how that constrains the solution

Proposed Solution
=================

The core elements we came up with, presented in a form that’s easy for people to immediately understand

Rabbit Holes
============

Details about the solution worth calling out to avoid problems. Such as deployability.

No-Gos
======

Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable

 

[ubuntugenx]

The next million-dollar app is here! Let us help you make your idea come to life.



We know what it's like starting out as an entrepreneur—you have a great idea but no money to make it happen. That's why we offer flexible payment plans so that you can get the services you need without having to worry about breaking the bank.



Our team of experienced developers will work with you every step of the way, from conception all the way through launch day so that you end up with something that exceeds your expectations and meets all of your needs. If this sounds like something that would be right up your alley then give us a call or send us an email today!