Select the offering that’s right for your business
3 day workshop
+ 2 weeks development
5 day workshop
+ 4 weeks development
- Web or mobile app
- AWS set-up
- 1 integration
- Two user groups
- Hi-ﬁ prototype
- Unmoderated user testing
- Manual test plan
- Three months Product Success consulting
4 week scope
+ variable development
- Web and/or mobile app
- Any hosting environment set-up
- Unlimited integrations
- Unlimited user groups
- Discovery interviews
- User journey maps
- Hi-ﬁ prototype
- Unmoderated/Moderated user testing
- Custom UI
- Manual test plan
- Three months Product Success consulting
*All prices are exclusive of GST
Read more about POC
Lower your risk by starting small.
Building a large product without ﬁrst validating it is risky. By starting small with a proof of concept you can make learnings early and lower your risk.
Improve your chances of raising investment and business buy in.
Everyone has an idea or concept. Success is dependent on execution.
Demonstrate to investors or your project sponsors that you can execute on your vision by building a proof of concept that has been validated by users.
When is POC
best for you?
The Proof of Concept engagement isn’t for everyone.
If the points below don’t describe you or your business, we’d recommend taking a look at our MVP or Product Development engagements.
- You need to validate your solution to raise further investment.
- Your solution is a very simple web platform with limited features and user groups.
- There are technical unknowns that must be investigated before building the complete product.
Apply to Secure Your Spot
We take on a limited number of POC engagements every month. The projects we choose have to meet minimum requirements and are then chosen on a ﬁrst in, best dressed basis. Apply here to reserve your spot.
3 Day Workshop + 10 Development Days
When building a POC, there needs to be an appropriate balance between being fast and keeping costs down while still having a quality enough product to prove or disprove a hypothesis. Some vendors believe it can be achieved in a 3 day engagement, we disagree.
With a 3 day workshop and two weeks of dedicated development, you have time to properly plan the project during the workshop while still leaving enough development time to build a quality deliverable. This is the sweet spot when it comes to building a proof of concept. The last thing you want from any engagement is to come out of it with something you don’t ﬁnd valuable.
Up to 1 API integration
An API (application programming interface) integration is essentially how different systems communicate with each other. If system A needs to send data to system B then they will do so through an API integration.
There are a number of beneﬁts to using an API. Firstly, it reduces the amount of data entry across your software landscape. Secondly, you can trigger automations in a different system based on actions taken on the POC. For example, if you create a job on your new job management POC, you may want to prompt an invoice to be created in your payroll system. Lastly, you may want to leverage pre-existing functionality built in another product. This is done through an API.
Integrate with up to two existing systems and create your uniﬁed software landscape.
Lite Product Backlog
A product backlog tells your development team exactly what to build. It helps align every stakeholder on what has been built and what is likely to come next. A lite product backlog differs slightly to a full product backlog. Because the scope and design phase is shorter in a POC, the product backlog can’t be as comprehensive.
A lite product backlog still includes a description of what will be built, alongside some acceptance criteria. Where it differs is that every feature is not scientifically estimated and there is no documented implementation plan.
The key beneﬁt is that it provides the necessary amount of documentation to ensure the application meets stakeholder expectations while still staying agile enough to be completed in a three-day workshop.
1 End User Group & 1 Admin User Group
A user group is a type of user likely to interact with your application. For example, let’s say you built a health monitoring application catered to doctors and nurses. Doctors may use the application for one purpose, and nurses use it for a different reason. This effectively means you have 2 End User Groups — Doctors and Nurses.
An admin user group is how you control the application. If your prices ever change or you need to export data into a CSV format, those actions are generally performed on the admin side of your application.
A POC focuses on a single user group while still providing admin control. This creates a single, concentrated focus for the product while it’s still being validated.
3rd Level Priority for Service Desk Support
A service desk is the conventional way for a product to be supported. For example, a bug is discovered on a particular device type, using a certain browser. Through the service desk, the product owner would log the behaviour that led to the bug as well as the device and browser that they were using (or for a mobile app, the version of the application).
This enables the support team to immediately replicate the bug that you discovered. Without that information, there is plenty of back and forth that delays the resolution time. Because a POC is aiming to validate the solution, it is unlikely that there are users consistently on the application. That is why the support team will prioritise POC projects third, below MVP and Product Development projects.
Web Platform Only
A web platform is highly accessible - anyone with access to Chrome or Safari can use a web app. It comprises a front end (what you see) and a backend (the database and everything that happens behind the scenes).
Its versatility and accessibility makes it the best platform to test and validate any solution. Using a single tech stack, you can create an application that can be used on a laptop, smartphone or tablet. Don’t tie yourself and your user base to a particular device without knowing with conﬁdence that it’s the best use of resources.
By starting with a web platform you can build fast, validate and expand to other platforms in the future.
AWS Environment Setup
Amazon Web Services (AWS) is the worlds largest cloud hosting provider. After creating your account a specialist DevOps engineer will setup your public cloud environment.
The setup is a dual-node which means you will have a backup database instantly kick in if the application or server crashes.
The server is backed nightly meaning your application’s data is safe and will not be lost.
Lastly, it is scalable and optimised, so your hosting can grow as your user base does. You’re not paying for processing power when its not needed.
This setup is the outcome of years of effort. If you were to hire a specialist DevOps engineer or third party hosting provider to create your AWS environment it would likely cost tens of thousands of dollars. This is included in the engagement so you can start testing your application.
When building software there are usually multiple environments that an application will progress through. A production environment is the ﬁnal staging environment and this is how your users will interact with your application.
It’s rare to see a Proof of Concept developed in a short span of time on its own production environment. Most commonly there will be a beta environment (beta.yourapp.com.au) that is used until a larger development build is completed.
A full production setup gives your proof of concept that extra credibility when raising investment and internal buy-in. You have the freedom to test and validate your POC on your own cloud environment, knowing you own and control your data.
Testing is the ultimate quality control mechanism. Testing comes in two forms, manual test plans and automated testing. Given the rapid nature of a POC project, manual test plans are de-prioritised. When going into further development in the future, it is recommended to take the time to build out these manual tests.
A key beneﬁt of the Codebots technology that we use is that it comes with out of the box automated testing. This means that the bots are testing their own code quality to ensure it is functioning as expected. Your team is able to build fast while knowing that automated tests come out of the box.
3 Months of Product Success Consults
Just because something is built, doesn’t mean it will succeed. This is the difference between building a product successfully and building a successful product. In order to effectively measure the success of your application, certain metrics need to be captured and reported on.
With a product success consultant, you’ll beneﬁt from a domain expert that will help manage and monitor your progress towards your goals. Because your product is unique, so too are the measurements of success. You’ll be stepped through a goal setting activity which will help form the basis for your consults going forward. It’s common for clients to use these reports for their board meetings and/or investor updates.
Sometimes the cheapest option isn’t right for you. When building a proof of concept, you’re validating an idea. That may mean de-prioritising usability or the interface of the application.
Yes, you can make small changes to your proof of concept on a time and materials basis through your service desk while in support. However, if you’re looking to make significant changes it may be necessary to go through a Product Development or MVP engagement. Based on your learnings and the changes to be made the team will recommend whether it’s better to add to the POC application or commence a re-build.
We’ve found that in order to build quality custom software you need a budget greater than $40K. There are options available if you don’t have the budget. The ﬁrst option we recommend is to ﬁnd an off the shelf system that solves the problem. Failing that, you may want to try to ﬁnd a technical co-founder - someone that can build the application in exchange for equity. If you proceed down this path we recommend using Codebots to leverage pre-built functionality and speed up development. The last option is to offshore to an overseas development house. We only recommend this as a last resort as there are risks associated with many offshore agencies.
A proof of concept is not a commercially viable application. Don’t expect to proceed through a POC engagement and get 20,000 users on your application. If you’re planning on creating a commercially viable product, then the MVP or Product Development engagements are better suited to your requirements.
No, do not expect to have your entire backlog built during a POC. The engagement is only two weeks and three days. There is no guarantee as to the scope that will be delivered in that time. That’s why it’s critical to prioritise your backlog and focus on a single problem statement.
Yes, there will be an opportunity to provide feedback and re-prioritise your backlog during the POC engagement. We schedule user acceptance testing (UAT’s) 2.5 days before the end of the engagement. This will give you an opportunity to review the application and prioritise the work to be done in the ﬁnal 2.5 days of the engagement.
You will be billed in weekly increments on the Wednesday preceding the start of the engagement, with 7 day payment terms.
There is a natural break point at the end of the workshop if both parties aren’t aligned on realistic objectives. In the event of a misalignment, the engagement can be terminated after the workshop and only the days worked are billable.
Stop asking the question, the answer is yes.
How might members retrieve their superannuation details in a quick and easy manner?
Can you remember your superannuation number? Chances are the answer is no. To solve this problem while still maintaining high security standards, BUSSQ built a proof of concept that linked with their CRM. After authorising that the user was who they said they were, they could access their information without trawling through their emails looking for their super number.
How might we replicate an existing stocktake app in a newer technology framework?
Ausco’s existing stocktake application was on a framework that was due to go end of life. The Proof of Concept was framed around how we could quickly replicate the existing application in a more modern tech stack. It included the ability to create and monitor the status of stock, with geofencing implemented to show where in the stockyard an item could be found.
How might we enable people to quickly apply for a loan online?
This POC was centred around creating the best possible user experience. Loan application processes are generally long and tedious. CreditOne wanted to determine how they could streamline the process through an online application. The power of the form was in its conﬁgurability. Administrators could log into the back end, update the form and set it live without writing a single line of code.
Apply to start your POC