1. Assumptions
The perceived need for a custom solution tends to come from one of the following assumptions:
- That you must “own” the platform
- That subscription-based platforms are more expensive over time than custom builds
- That your project requirements are too unique for existing platforms
And more often than not these assumptions are false.
Ask yourself why you need to “own” the platform? If you are concerned about the longevity of a subscription based platform you can research who is behind it, what kind of investments they have received and their perceived market size and value. All of this will give a reasonable indication of their stability. Having full control over your website platform as the sole reason, is not worth the effort and cost of building a custom website.
A subscription-based platform will rarely be more expensive than custom builds within any reasonable amount of time. 100$ / month would be considered a high-end subscription platform. At that rate it would take 5 years to cost as much as a cheap custom built website. And that is not even factoring in that the subscription includes: hosting, security, 24/7 support, free upgrades, debugging, testing, new modules and features and much more. The security, quality, scalability and feature set will also likely be significantly better than the cheap custom build. A custom build with a similar level of stability, scalability and support would easily cost 5 times as much. Cost should never be a reason to opt for a custom built website.
A project with unique requirements is where I will sit down for an in-depth discussion with the prospect to really understand their needs and ensure there are no existing platforms that can meet those needs or at least close enough to do an initial launch. Every custom project we architect is guaranteed to have business or technical requirements that simply cannot be satisfied by existing platforms. Unique requirements are one of the few valid reason to build a custom website.
2. What are you trying to achieve?
Stop and consider this carefully. What is your business trying to achieve? Are you trying to sell a product or a service? And is a custom website essential to achieving that? Often it is not. If you are starting up an eCommerce business for example, your goal is to sell your product. Having a showy website with the latest in high-tech gimmickry is unlikely to sell more products. You are far more likely to reach more people by putting those funds towards marketing.
Get your product on one of the many available cloud eCommerce platforms such as Shopify. Put your resources into marketing and build your client database and revenue. When this is running successfully and you have proven that your product is market worthy, then you can build that web-based 3D VR HTML5 product configurator you really wanted.
3. Do it right and understand the full cost beforehand
For custom built applications my recommendation is to do it right. Most importantly: have the budget and the time to do it right. Custom projects will have high resource requirements - always more than you think. Custom projects should never be done on a tight deadline - you need to take your time to get it right and accept that you might not meet that “hard deadline” you were hoping for. Managing your own expectations this way is essential.
The vendor estimate is but a fraction of the cost. Whatever they estimate, you need to add risk margins. These risk margins run from 15% to 150% depending on many variables such as experience of the vendor, their location, timezone and language barriers, how often you will want changes to the website during development and how clear your initial brief is. We have a complex risk model that we are planning to make publicly available in the near future to help calculate this margin.
The added risk margins also apply to the time line, so you need to factor in your own time to manage the vendor or additional cost to pay someone to manage them for this potentially extended period. Then there are ongoing hosting and maintenance costs, server upgrades and security fixes. While they apply to any project platform, don’t forget marketing costs which could easily cost the same or more as the design and development of a custom website.
Here is a simple test: take the budget you were hoping to spend, times that by 5. Does that amount sound impossible? Then don’t do a custom project. Reduce your requirements and find a way to use an existing platform. At least for now, until that x 5 number sounds achievable.
Also, do not start on a custom website thinking you will get the money later, this almost never works out well. Have the funds, including the margins, on your account before committing to anything. Either your own resources or cash received from an investor or a grant. Just make sure you have full and guaranteed access to it before signing on with a vendor. Projects that run out of budget mid-development are not uncommon and it is frustrating to all involved. Your attitude towards your idea will sour and your developer might not want to continue with you. Whatever you have spent on the project will be wasted. Not a good place to be in.
Lastly, make sure solution architecture is done before any development starts. If the vendor does not have a Solution Architect (or something similar under a different name) then find a third party to help you with this. A competent Solution Architect will ensure that the project is done right, that all the information needed for making key decisions is at your finger tips and that vendors are appropriately evaluated for their abilities, experience and compatibility with your project.
4. Understand how a vendor works to get an indication of quality
Take your time to evaluate the vendor and understand how they work. Ask them about their development cycles and testing procedures. If they are not sure, or cannot give a clear answer, I would consider this a red flag. What you want to hear is that they have a clear, well thought out workflow and that they do testing with dedicated testers and not only the developers themselves.
Vendors that discuss your requirements in more detail is also a good sign. If they are asking questions and suggesting alternative implementations then this shows they are thinking with you and trying to ensure your website will be a success. Developers that don’t really care about the success of your project will usually just implement whatever is requested without questioning. If you feel you have to keep repeating the same thing over and over again this may indicate the red flag of miscommunication - a very costly thing in custom development.
Make sure testing and project management is included in the estimate and confirm there are no other hidden costs. At least 25% of the development budget/time should be testing. PM budget varies between vendors.
Ask them if they add error/risk margins to their estimate and check what percentage they add. It should be at least 20% so add an additional margin to the estimate as needed. If they don’t add any margin or they are not transparent about this I would consider it a red flag.
Check if they "think before they build". They should have steps in place such as debrief, technical plan, wire framing, design and only then should they start development. Walk away from any vendor telling you “they will just start developing to save costs”. It might sound like it will save costs to start but it really won’t by the time they finish developing.
5. Ensure portability of code
Ask what framework they are using and do some research into how common that framework is. A more common framework will make it easier to find other developers to take over the project in the future. If it is a proprietary framework then make sure you get the full source code once the project is completed and find out the benefits of their framework over more common open source ones. Scalability or strong integration with a specific cloud service provider are usually good reasons for example.
Some of the top PHP frameworks are: Laravel, Phalcon, Symfony 2, Yii and Codeigniter. Other common programming languages include nodejs and Python. Unless you are dealing directly with financial institutions I would generally advise against the use of Java in custom websites as it is significantly more costly to develop with and maintain.
6. Get a long-term estimate
Ask the vendor to provide an estimate for the total cost of project over 3 years. The estimate should include hosting costs and any maintenance to ensure the servers and software stay up to date as well as strong security and system stability. This 3 year cost is a much better comparison between different vendors than only the build. It is also a better comparison against subscription platforms. Indicate that the vendor will be responsible for the security of the servers. This should ensure that nothing is left out of the estimate to achieve that.
7. Don’t do fixed price
I always recommend against a fixed-price approach. While it may sound attractive at first, when budgets start to creep then fixed price projects tend to get sidelined or corners are cut in quality, testing and security. All of which would be hard to detect until something goes horribly wrong in your live website. Vendors that do not have a fixed price offer tend to be better at estimation and more transparent and clear with their pricing and billing of actual hours worked. More information about that here: There are no winners in Fixed Price
8. Don’t use WordPress for custom websites
Unless you are doing a blog or a simple website, do not use WordPress. If you ask around for an affordable custom built application it is likely you would get at least a few WordPress based offers that seem very affordable. If you are going beyond blog/simple website then a lot of the functionality you need will not be available in the standard WordPress package and you will be dependent on third party plugins or custom work. This will make your maintenance costs significantly higher and greatly increase the security risks to your platform - certainly if WordPress is not upgraded every 3 months out of fear of breaking plugins or custom work.
9. Get the source!
Always ensure that the vendor will provide you with the full source code at some point. Usually after you have fully paid for the project. You have paid for a custom website and you absolutely have a right to the source code in this case. Don’t let a developer tell you otherwise.
The reason why I always recommend frequent invoicing - every 2 or 4 weeks for example, is that this means you should get access to new source code just as frequently.
When you receive the source code I advise having a third party do a quick review of it to make sure it’s not encrypted or otherwise protected. They can also check the quality of the source code before it is too late to do anything about it. The PHP programming language is more likely to have messy code than other languages due to its flexible nature so this should absolutely be quality controlled during development.
10. Programming language decisions
Most custom application vendors will offer PHP implementations. Usually because PHP developers are easy to find. But do consider alternatives. Many custom applications that I architect these days are developed with a nodejs backend on AWS Lambda service and an angular frontend on AWS S3. This makes the application entirely serverless which practically eliminates maintenance costs and reduces your 0-load hosting cost to almost nothing. You are literally only paying for what you are using and never more. It also has the benefit of making your entire application Javascript (an open source language like PHP). This means that a single Javascript developer could maintain both your front-end and back-end should you decide to hire an in-house staff for this.