1–10 of 111 posts
I've been googling, but can't seem to get a straight answer. It seems like there's an initial project cost & then maintenance revenue ongoing for the software / app's life. Is that accurate?
Appreciate any insight y'all can provide!
There's also often a clause giving the company rights to use bits of the software in future projects (but not to sell them standalone.) That way future projects can be much faster to develop, there's a lot of overlap in these things.
There is no fixed model to this but largely what you said is what the standard is!
Some upfront cost is always taken from the customer before starting the project and then paid in full once project is delivered.
Post that it depends what customer wants. They can keep paying you to maintain it regularly and fix bugs. Also you can charge them for some additional feature development. (This is called account expansion revenue in business terms.)
Fixed bid is relatively simple: company says project will cost X dollars, and takes on the risk of that amount ending up being too low. As a consequence, these projects tend to be very rigid; if a client wants any changes made to the plan or outcome, typically that involves another charge (unless certain revisions were allowed for up front).
Estimated cost is just that- firm offers a guesstimate of the total project cost, but only actually charges for the total number of human-hours worked. These contracts can be a bit more flexible- sales may tweak the hourly rate to keep clients happy, changes can be incorporated if the client is willing to sign off on a new estimate, etc.
One newer and slightly less common variation during initial development is capacity based- again, a very rough outline for project timeline may be put together up front (businesses like plans) but the company bills a flat rate to provide hours per week, rather than progress towards a dedicated plan. This allows for a more "agile" workflow, and is also happens to be a common arrangement for maintenance phases where a client may choose whether to add new features or work out existing kinks without needing to sign a new agreement for every little feature. It offers the most flexibility for clients while also putting most of the risk on them as the development shop hasnt agreed to any specific outcomes.
There were different types of revenue streams.
First are open projects for multiple companies to apply for, convince the clients they are the best party for x amount of money. These project’s are large, and requires also quite a bit of investments for the company competing for the project.
These are usually fixed price fixed scope projects. After finishing the project there often are several other contract types. ALM application lifecycle management contracts, these are often x amount of hour to per month. To keep the system’s up to date, Fix bugs that pop up and creating uptime reports and such.
Often there’s also an amount of money per month for on call support. The projects need to be kept running 24/7 so if something breaks in the middle of the night someone needs to wake up and try to fix it.
Other types of revenue are teams/individuals for hire. Imagine the customer having a few engineers and the consulting firm supply a few hands. They can be a range of roles, testers, frontend backend, scrum masters depending on the snake oil they company is selling ;).
There is also projects that happen together with FANG. Google and Microsoft are quite notorious for helping companies like mine to our connect with our customers. Helping them while including the latest whistles and bells of there offerings. That is also why many companies value certificates from Microsoft and Google etc. They get discount of cloud pricing, so they get a cut from what they pay for the infrastructure.
On systems that are in maintenance mode there are also some often RFCs (request for change) as larger changes with the system that is in maintenance mode.
Instead of waterfall projects the alternatives is to sell x amount of sprints or design sprints. But in my experience large companies and agile that it doesn’t really works
2) You discuss with the clients what's their needs.
3) Figure out what you can do and agree with the client on the billing/project. (how many people? of what skills? how long? what to build? for how much?)
4) Do the work. Projects could be anywhere from weeks to years.
5) Long time goes bye.
6) Done.
There's two ways to handle the billing and making money aspect.
First option. Bill per time. You basically promise to have X people of various skillset working on the project for some period of time. They're each billed $$$ per day so it's simple math.
Second option, harder to manage. Bill per project. You basically promise to deliver a bunch of features or some result that's agreed upon at the start. This one is tricky because you have to define everything at the beginning and clients usually don't know what they want and change their mind.
Now, who wants to have a longer blog post about the difference between contracting and tech companies?
1) Clients come to you because they have a painpoint and they wand to build something to help it. 2) You discuss with the clients what's their needs. 3) Figure out what you can do and agree with the client on the billing/project. (how many people? of what skills? how long? what to build? for how much?) 4) Do the work. Projects could be anywhere from weeks to years. 5) Long time goes bye. 6) Done. There's two ways to…
The advantage is that you have clearly defined goals, but the client can still change direction of they need to (by adjusting the next sprint).