Proof of Concept

Build, test and val­i­date your POC for a fixed price in 3 weeks.

A proof of con­cept is an ex­per­i­ment or pi­lot pro­ject to demon­strate fea­si­bil­ity of a de­sign con­cept or a busi­ness pro­posal.

Low risk and light­ning fast.

POCs are time-fixed, com­pris­ing of a 3-day scop­ing work­shop and 2 weeks of de­vel­op­ment. This sets your bud­get from the get go and al­lows you to val­i­date your idea with users quickly. A POC is a low-risk way of let­ting in­vestors know you can ex­e­cute on your vi­sion.

In the dri­ver’s seat.

At the con­clu­sion of POC de­vel­op­ment you have the op­tion to make small changes to the ap­pli­ca­tion via our ser­vice desk. Bigger changes may ne­ces­si­tate an MVP or Product Development engagement, but you have full con­trol over how much you want to add to the app and when.

Automated test­ing.

Testing is the ul­ti­mate qual­ity con­trol mech­a­nism. While a POC should­n’t be rolled out to a large num­ber of users, au­to­mated test­ing re­duces the risk of func­tion­al­ity not work­ing as ex­pected. Util­is­ing the Codebots tech­nol­ogy means there are au­to­mated tests ready to strengthen the qual­ity of your ap­pli­ca­tion.

Project Artefacts.

Aside from your POC ap­pli­ca­tion, our de­sign­ers and de­vel­op­ers will also cre­ate user flow di­a­grams, a back­log and UI de­signs, along with any other arte­facts in­ci­den­tal to the work­shop. These arte­facts can in­form any fu­ture de­vel­op­ment you may choose to do.

POC Process

When is POC
best for you?

The Proof of Concept en­gage­ment is­n’t for every­one.

If the points be­low don’t de­scribe you or your busi­ness, we’d rec­om­mend tak­ing a look at our MVP or Product Development en­gage­ments.

  • You need to val­i­date your so­lu­tion to raise fur­ther in­vest­ment.
  • Your so­lu­tion is a very sim­ple web plat­form with lim­ited fea­tures and user groups.
  • There are tech­ni­cal un­knowns that must be in­ves­ti­gated be­fore build­ing the com­plete prod­uct.

At A Glance


5 day work­shop

+ 4 weeks de­vel­op­ment

  • Web or mo­bile app
  • AWS set-up
  • 1 in­te­gra­tion
  • Two user groups
  • Hi-fi pro­to­type
  • Unmoderated user test­ing
  • Backlog
  • Manual test plan
  • Three months Product Success con­sult­ing


4 week scope

+ vari­able de­vel­op­ment

  • Web and/​or mo­bile app
  • Any host­ing en­vi­ron­ment set-up
  • Unlimited in­te­gra­tions
  • Unlimited user groups
  • Discovery in­ter­views
  • User jour­ney maps
  • Hi-fi pro­to­type
  • Unmoderated/Moderated user test­ing
  • Custom UI
  • Backlog
  • Manual test plan
  • Estimations
  • Roadmap
  • Three months Product Success con­sult­ing


Let us tai­lor a pack­age for you

Contact us

Read more about POC

Apply to Secure Your Spot

We take on a lim­ited num­ber of POC en­gage­ments every month. The pro­jects we choose have to meet min­i­mum re­quire­ments and are then cho­sen on a first in, best dressed ba­sis. Apply here to re­serve your spot.

Key in­clu­sions

3 Day Workshop + 10 Development Days

Start rapidly pro­to­typ­ing your POC over the course of a 3-day work­shop. You’ll cre­ate your pri­or­ity list be­fore head­ing into a lean 2 week build to get a POC ready for test­ing!

When build­ing a POC, there needs to be an ap­pro­pri­ate bal­ance be­tween be­ing fast and keep­ing costs down while still hav­ing a qual­ity enough prod­uct to prove or dis­prove a hy­poth­e­sis. Some ven­dors be­lieve it can be achieved in a 3-day en­gage­ment, we dis­agree.

With a 3-day work­shop and two weeks of ded­i­cated de­vel­op­ment, you have time to prop­erly plan the pro­ject dur­ing the work­shop while still leav­ing enough de­vel­op­ment time to build a qual­ity de­liv­er­able. This is the sweet spot when it comes to build­ing a proof of con­cept. The last thing you want from any en­gage­ment is to come out of it with some­thing you don’t find valu­able.

Up to 1 API in­te­gra­tion

An API (application pro­gram­ming in­ter­face) in­te­gra­tion is how dif­fer­ent sys­tems com­mu­ni­cate with each other. Connect your ap­pli­ca­tions to re­duce data en­try, au­to­mate tasks, re­duce hu­man er­ror and save costs.

An API (application pro­gram­ming in­ter­face) in­te­gra­tion is es­sen­tially how dif­fer­ent sys­tems com­mu­ni­cate with each other. If sys­tem A needs to send data to sys­tem B then they will do so through an API in­te­gra­tion.

There are a num­ber of ben­e­fits to us­ing an API. Firstly, it re­duces the amount of data en­try across your soft­ware land­scape. Secondly, you can trig­ger au­toma­tions in a dif­fer­ent sys­tem based on ac­tions taken on the POC. For ex­am­ple, if you cre­ate a job on your new job man­age­ment POC, you may want to prompt an in­voice to be cre­ated in your pay­roll sys­tem. Lastly, you may want to lever­age pre-ex­ist­ing func­tion­al­ity built in an­other prod­uct. This is done through an API.

Integrate with ex­ist­ing sys­tems and cre­ate a uni­fied soft­ware land­scape.

Lite Product Backlog

A prod­uct back­log tells your de­vel­op­ment team ex­actly what to build. This creates the di­rec­tion and struc­ture you need to de­liver a suc­cess­ful pro­ject.

It helps align every stake­holder on what has been built and what is likely to come next. A lite prod­uct back­log dif­fers slightly to a full prod­uct back­log. Because the scope and de­sign phase is shorter in a POC, the prod­uct back­log can’t be as com­pre­hen­sive.

A lite prod­uct back­log still in­cludes a de­scrip­tion of what will be built, along­side some ac­cep­tance cri­te­ria. Where it dif­fers is that every fea­ture is not sci­en­tif­i­cally es­ti­mated and there is no doc­u­mented im­ple­men­ta­tion plan.

The key ben­e­fit is that it pro­vides the nec­es­sary amount of doc­u­men­ta­tion to en­sure the ap­pli­ca­tion meets stake­holder ex­pec­ta­tions while still stay­ing ag­ile enough to be com­pleted in a three-day work­shop.

1 End User Group & 1 Admin User Group

A user group is a type of user likely to in­ter­act with your ap­pli­ca­tion. A POC is de­signed to fo­cus in on one type of user, while still pro­vid­ing back­end ad­min func­tion­al­ity.

For ex­am­ple, let’s say you built a health mon­i­tor­ing ap­pli­ca­tion catered to doc­tors and nurses. Doctors may use the ap­pli­ca­tion for one pur­pose, and nurses use it for a dif­fer­ent rea­son. This ef­fec­tively means you have 2 End User Groups — Doctors and Nurses.

An ad­min user group is how you con­trol the ap­pli­ca­tion. If your prices ever change or you need to ex­port data into a CSV for­mat, those ac­tions are gen­er­ally per­formed on the ad­min side of your ap­pli­ca­tion.

A POC fo­cuses on a sin­gle user group while still pro­vid­ing ad­min con­trol. This cre­ates a sin­gle, con­cen­trated fo­cus for the prod­uct while it’s still be­ing val­i­dated.

3rd Level Priority for Service Desk Support

You won’t be left stranded af­ter the build is done. Support is pro­vided to save the day, with POC prod­ucts get­ting third level ser­vice desk pri­or­ity.

A ser­vice desk is the con­ven­tional way for a prod­uct to be sup­ported. For ex­am­ple, a bug is dis­cov­ered on a par­tic­u­lar de­vice type, us­ing a cer­tain browser. Through the ser­vice desk, the prod­uct owner would log the be­hav­iour that led to the bug as well as the de­vice and browser that they were us­ing (or for a mo­bile app, the ver­sion of the ap­pli­ca­tion).

This en­ables the sup­port team to im­me­di­ately repli­cate the bug that you dis­cov­ered. Without that in­for­ma­tion, there is plenty of back and forth that de­lays the res­o­lu­tion time. Because a POC is aim­ing to val­i­date the so­lu­tion, it is un­likely that there are users con­sis­tently on the ap­pli­ca­tion. That is why the sup­port team will pri­ori­tise POC pro­jects third, be­low MVP and Product Development pro­jects.

Web Platform Only

A web plat­form is highly ac­ces­si­ble - any­one with ac­cess to Chrome or Safari can use a web app. By start­ing with a web plat­form you can build fast, val­i­date and ex­pand to a mo­bile app in the fu­ture.

It com­prises a front end (what you see) and a back­end (the data­base and every­thing that hap­pens be­hind the scenes). Its ver­sa­til­ity and ac­ces­si­bil­ity makes it the best plat­form to test and val­i­date any so­lu­tion. Using a sin­gle tech stack, you can cre­ate an ap­pli­ca­tion that can be used on a lap­top, smart­phone or tablet.

Don’t tie your­self and your user base to a par­tic­u­lar de­vice with­out know­ing with con­fi­dence that it’s the best use of re­sources.

AWS Environment Setup

Amazon Web Services is the worlds largest cloud host­ing provider. After cre­at­ing your ac­count a spe­cial­ist DevOps en­gi­neer will setup your en­vi­ron­ment. This process would nor­mally cost tens of thou­sands of dol­lars.

The setup is a dual-node which means you will have a backup data­base in­stantly kick in if the ap­pli­ca­tion or server crashes.

The server is backed nightly mean­ing your ap­pli­ca­tion’s data is safe and will not be lost.

The server is backed nightly mean­ing your ap­pli­ca­tion’s data is safe and will not be lost.

Lastly, it is scal­able and op­ti­mised, so your host­ing can grow as your user base does. You’re not pay­ing for pro­cess­ing power when its not needed.

This setup is the out­come of years of ef­fort. If you were to hire a spe­cial­ist DevOps en­gi­neer or third party host­ing provider to cre­ate your AWS en­vi­ron­ment it would likely cost tens of thou­sands of dol­lars. This is in­cluded in the en­gage­ment so you can start test­ing your ap­pli­ca­tion.

Production Release

A pro­duc­tion re­lease means your ap­pli­ca­tion is live! It has all the ben­e­fits of go­ing through test­ing en­vi­ron­ments and gives you a clean slate to start test­ing your user base.

When build­ing soft­ware there are usu­ally mul­ti­ple en­vi­ron­ments that an ap­pli­ca­tion will progress through. A pro­duc­tion en­vi­ron­ment is the fi­nal stag­ing en­vi­ron­ment and this is how your users will in­ter­act with your ap­pli­ca­tion.

It’s rare to see a Proof of Concept de­vel­oped in a short span of time on its own pro­duc­tion en­vi­ron­ment. Most com­monly there will be a beta en­vi­ron­ment ( that is used un­til a larger de­vel­op­ment build is com­pleted.

A full pro­duc­tion setup gives your proof of con­cept that ex­tra cred­i­bil­ity when rais­ing in­vest­ment and in­ter­nal buy-in. You have the free­dom to test and val­i­date your POC on your own cloud en­vi­ron­ment, know­ing you own and con­trol your data.

Automated Testing

Testing is the ul­ti­mate qual­ity con­trol mech­a­nism. While a POC should­n’t be rolled out to a large num­ber of users, au­to­mated test­ing re­duces the risk of func­tion­al­ity not work­ing as ex­pected.

Testing comes in two forms, man­ual test plans and au­to­mated test­ing. Given the rapid na­ture of a POC pro­ject, man­ual test plans are de-pri­ori­tised. When going into fur­ther de­vel­op­ment in the fu­ture, it is rec­om­mended to take the time to build out these man­ual tests.

A key ben­e­fit of the Codebots tech­nol­ogy that we use is that it comes with out of the box au­to­mated test­ing. This means that the bots are test­ing their own code qual­ity to en­sure it is func­tion­ing as ex­pected. Your team is able to build fast while know­ing that au­to­mated tests come out of the box.

3 Months of Product Success Consults

Just be­cause some­thing is built, does­n’t mean it will suc­ceed. A cus­tomer suc­cess con­sul­tant will walk you through ac­tiv­i­ties and plat­forms that can help you find your prod­uct mar­ket fit.

This is the dif­fer­ence be­tween build­ing a prod­uct suc­cess­fully and build­ing a suc­cess­ful prod­uct. In or­der to ef­fec­tively mea­sure the suc­cess of your ap­pli­ca­tion, cer­tain met­rics need to be cap­tured and re­ported on.

With a cus­tomer suc­cess con­sul­tant, you’ll ben­e­fit from a do­main ex­pert that will help man­age and mon­i­tor your progress to­wards your goals. Because your prod­uct is unique, so too are the mea­sure­ments of suc­cess. You’ll be stepped through a goal set­ting ac­tiv­ity which will help form the ba­sis for your con­sults go­ing for­ward. It’s com­mon for clients to use these re­ports for their board meet­ings and/​or in­vestor up­dates.


Sometimes the cheap­est op­tion is­n’t right for you. When build­ing a proof of con­cept, you’re val­i­dat­ing an idea. That may mean de-pri­ori­tis­ing us­abil­ity or the in­ter­face of the ap­pli­ca­tion.

Yes, you can make small changes to your proof of con­cept on a time and ma­te­ri­als ba­sis through your ser­vice desk while in sup­port. However, if you’re look­ing to make sig­nif­i­cant changes it may be nec­es­sary to go through a Product Development or MVP en­gage­ment. Based on your learn­ings and the changes to be made the team will rec­om­mend whether it’s bet­ter to add to the POC ap­pli­ca­tion or com­mence a re-build.

We’ve found that in or­der to build qual­ity cus­tom soft­ware you need a bud­get greater than $40K. There are op­tions avail­able if you don’t have the bud­get. The first op­tion we rec­om­mend is to find an off the shelf sys­tem that solves the prob­lem. Failing that, you may want to try to find a tech­ni­cal co-founder - some­one that can build the ap­pli­ca­tion in ex­change for eq­uity. If you pro­ceed down this path we rec­om­mend us­ing Codebots to lever­age pre-built func­tion­al­ity and speed up de­vel­op­ment. The last op­tion is to off­shore to an over­seas de­vel­op­ment house. We only rec­om­mend this as a last re­sort as there are risks as­so­ci­ated with many off­shore agen­cies.

A proof of con­cept is not a com­mer­cially vi­able ap­pli­ca­tion. Don’t ex­pect to pro­ceed through a POC en­gage­ment and get 20,000 users on your ap­pli­ca­tion. If you’re plan­ning on cre­at­ing a com­mer­cially vi­able prod­uct, then the MVP or Product Development en­gage­ments are bet­ter suited to your re­quire­ments.

No, do not ex­pect to have your en­tire back­log built dur­ing a POC. The en­gage­ment is only two weeks and three days. There is no guar­an­tee as to the scope that will be de­liv­ered in that time. That’s why it’s crit­i­cal to pri­ori­tise your back­log and fo­cus on a sin­gle prob­lem state­ment.

Yes, there will be an op­por­tu­nity to pro­vide feed­back and re-pri­ori­tise your back­log dur­ing the POC en­gage­ment. We sched­ule user ac­cep­tance test­ing (UAT’s) 2.5 days be­fore the end of the en­gage­ment. This will give you an op­por­tu­nity to re­view the ap­pli­ca­tion and pri­ori­tise the work to be done in the fi­nal 2.5 days of the en­gage­ment.

You will be billed in weekly in­cre­ments on the Wednesday pre­ced­ing the start of the en­gage­ment, with 7 day pay­ment terms.

There is a nat­ural break point at the end of the work­shop if both par­ties aren’t aligned on re­al­is­tic ob­jec­tives. In the event of a mis­align­ment, the en­gage­ment can be ter­mi­nated af­ter the work­shop and only the days worked are bill­able.

Stop ask­ing the ques­tion, the an­swer is yes.

Past POC’s

How might mem­bers re­trieve their su­per­an­nu­a­tion de­tails in a quick and easy man­ner?

Can you re­mem­ber your su­per­an­nu­a­tion num­ber? Chances are the an­swer is no. To solve this prob­lem while still main­tain­ing high se­cu­rity stan­dards, BUSSQ built a proof of con­cept that linked with their CRM. After au­tho­ris­ing that the user was who they said they were, they could ac­cess their in­for­ma­tion with­out trawl­ing through their emails look­ing for their su­per num­ber.

How might we repli­cate an ex­ist­ing stock­take app in a newer tech­nol­ogy frame­work?

Ausco’s ex­ist­ing stock­take ap­pli­ca­tion was on a frame­work that was due to go end of life. The Proof of Concept was framed around how we could quickly repli­cate the ex­ist­ing ap­pli­ca­tion in a more mod­ern tech stack. It in­cluded the abil­ity to cre­ate and mon­i­tor the sta­tus of stock, with ge­ofenc­ing im­ple­mented to show where in the stock­yard an item could be found.

How might we en­able peo­ple to quickly ap­ply for a loan on­line?

This POC was cen­tred around cre­at­ing the best pos­si­ble user ex­pe­ri­ence. Loan ap­pli­ca­tion processes are gen­er­ally long and te­dious. CreditOne wanted to de­ter­mine how they could stream­line the process through an on­line ap­pli­ca­tion. The power of the form was in its con­fig­ura­bil­ity. Administrators could log into the back end, up­date the form and set it live with­out writ­ing a sin­gle line of code.

Apply to start your POC

Your vi­sion,

our ex­per­tise

Book a strat­egy ses­sion