Product Development

Scope, build and launch your prod­uct us­ing a qual­ity dri­ven process.

Product de­vel­op­ment cov­ers the com­plete process of bring­ing a new prod­uct to mar­ket, re­new­ing an ex­ist­ing prod­uct or in­tro­duc­ing a prod­uct in a new mar­ket.

Select the of­fer­ing that’s right for your busi­ness


3 day work­shop

+ 2 weeks de­vel­op­ment

  • Web plat­form only
  • AWS set-up
  • One in­te­gra­tion
  • One user group
  • Hi-fi de­signs
  • Lite back­log
  • Automated test plan
  • Three months Product Success con­sult­ing


5 day work­shop

+ 4 weeks de­vel­op­ment

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

*All prices are ex­clu­sive of GST

Read more about POC

Mitigate your risks with a proven process.

Large scale soft­ware pro­jects carry risk. This is nat­ural in a highly com­plex en­vi­ron­ment. How­ever, if left unchecked these risks can blow the pro­jects bud­get and se­verely im­pact the qual­ity of the fi­nal prod­uct. Benefit from a tried and tested Way of Working that’s been de­signed to mit­i­gate these risks.

Scale up, in­crease your rev­enue and re­duce your costs.

With cus­tom soft­ware you can scale up know­ing you have an ap­pli­ca­tion that can scale with you. It opens new av­enues for li­cens­ing rev­enue since you own the in­tel­lec­tual prop­erty! Grow your busi­ness with this new stream of re­cur­ring rev­enue or, al­ter­na­tively, by sav­ing costs au­tomat­ing those time-con­sum­ing tasks.

Product Development Process

When is Product Development
best for you?

The Product Development of­fer­ing will nat­u­rally suit those large-scale pro­jects. Size is in­flu­enced by two fac­tors — com­plex­ity and the num­ber of fea­tures.

We’d rec­om­mend Product Development if you fit into one of the cat­e­gories be­low:

  • You have a de­fined scope and need the en­tire scope to launch your prod­uct.
  • You are build­ing a highly com­plex ap­pli­ca­tion.
  • You re­quire both a mo­bile and a web ap­pli­ca­tion.
  • There are more than two user groups ex­pected to use the ap­pli­ca­tion.

Apply to Secure Your Spot

We take on a lim­ited num­ber of Product Development en­gage­ments every month. Projects are sched­uled on a first in, best dressed ba­sis. It’s highly rec­om­mended to ap­ply as soon as pos­si­ble, in or­der to se­cure your spot.

Key in­clu­sions

4 Weeks Scope and Variable Development

A 4 week scope gives the en­tire team an op­por­tu­nity to deep dive into the prob­lem state­ment and doc­u­ment a de­tailed so­lu­tion. A scope is work com­pleted at the start of the pro­ject to en­sure that it is set up with every arte­fact it needs to suc­ceed. Examples of these arte­facts in­clude a hi-fi pro­to­type, prod­uct back­log, es­ti­ma­tions and ad­e­quate user test­ing.

A scope en­sures that any tech­ni­cal ques­tions or points of am­bi­gu­ity can be in­ves­ti­gated and mit­i­gated be­fore pro­ceed­ing into de­vel­op­ment.

A vari­able de­vel­op­ment time means you can vary the length of the pro­ject based on bud­get or fea­tures. At the end of the 4 week scope you’ll know what your back­log is and how long de­vel­op­ment is likely to take. That’s your op­por­tu­nity to set a time­frame that works best for your pro­ject.

Web and/​or Mo­bile App

Engage your users on their pre­ferred plat­form.

A web plat­form is highly ac­ces­si­ble - any­one with ac­cess to Chrome or Sa­fari can use a web app. 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.

A mo­bile app on the other hand is only ac­ces­si­ble on mo­bile de­vices. The key ad­van­tage is that it can utilise your phone’s na­tive de­vice set­tings (like your lo­ca­tion or mi­cro­phone) which can lead to a much bet­ter user ex­pe­ri­ence.

While our rec­om­men­da­tion is to fo­cus on one plat­form at a time, Product Development gives you the op­por­tu­nity to meet your users on their pre­ferred plat­form.

Any Host­ing En­vi­ron­ment Setup

You have the flex­i­bil­ity to choose where you want your ap­pli­ca­tion hosted. Our gen­eral rec­om­men­da­tion is to choose a pub­lic cloud en­vi­ron­ment like AWS. However if there are fac­tors that re­quire your ap­pli­ca­tion to be hosted else­where, like on premise, this is also avail­able with Product Development.

After cre­at­ing your ac­count a spe­cial­ist DevOps en­gi­neer will setup your cloud en­vi­ron­ment at a time and ma­te­ri­als rate. The stan­dard 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. 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 en­vi­ron­ment it would likely cost tens of thou­sands of dol­lars.

Unlimited API in­te­gra­tions

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 prod­uct. For ex­am­ple, if you cre­ate a job on your new job man­age­ment app, 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 as many sys­tems as you need to cre­ate your uni­fied soft­ware land­scape.

Unlimited User Groups

A user group is a type of user likely to in­ter­act with your ap­pli­ca­tion. 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. Doc­tors may use the ap­pli­ca­tion for one pur­pose, and nurses use it for a dif­fer­ent rea­son. This effectively 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.

With Product Development you have the flex­i­bil­ity to cre­ate a prod­uct for as many user types as you need. We rec­om­mend keep­ing this low to be­gin with as adding too many user groups cre­ates com­plex­ity, mean­ing ad­di­tional de­vel­op­ment time.

Discovery In­ter­views & User Testing

You can build the best prod­uct in the world, at the end of the day if no one uses it, then your prod­uct is des­tined to fail. User test­ing is the clos­est you’ll get to be­ing able to read your user’s mind.

Discovery in­ter­views are a way of un­der­stand­ing the user be­fore de­sign be­gins. By ask­ing pre­lim­i­nary ques­tions that dive into their core prob­lems, the first it­er­a­tion of the pro­to­type will be closer to the fi­nal so­lu­tion than if we were to de­sign blindly.

User test­ing is com­pleted dur­ing the 4 week scope us­ing a hi-fi pro­to­type. The key ben­e­fit is that you’re get­ting feed­back early and of­ten on the prod­uct from peo­ple likely to use it. This feed­back is in­cor­po­rated in the next it­er­a­tion of the prod­ucts de­sign. You’re mitigating your risks to give your prod­uct the best pos­si­ble chance of achiev­ing prod­uct mar­ket fit.

User Jour­ney Maps

A user jour­ney map is a vi­sual rep­re­sen­ta­tion of the cus­tomer ex­pe­ri­ence. For ex­am­ple, Glen is a farmer who logs into the app and in­puts his har­vest. He is then sent a con­fir­ma­tion email to ver­ify the de­tails he in­put are cor­rect. Glen comes back to the app in 3 days time and finds an of­fer has been placed to pur­chase his har­vest. Glen ac­cepts the of­fer which pro­vides the con­tact de­tails of the buyer. The pur­chase is then arranged out­side of the ap­pli­ca­tion.

Mapping out ex­actly how dif­fer­ent user types will in­ter­act with your ap­pli­ca­tion can greatly ben­e­fit the over­all user ex­pe­ri­ence. By vi­su­ally see­ing the flow of a user through the app, you can recog­nise op­por­tu­ni­ties to op­ti­mise or stream­line the ex­pe­ri­ence. User journey maps are cre­ated dur­ing the 4 week scope to al­low for any changes to flow into the de­sign and de­vel­op­ment of the ap­pli­ca­tion.

Hi-fi Pro­to­type

A high fi­delity (hi-fi) pro­to­type is a rep­re­sen­ta­tion of the prod­uct in sta­tic form. This en­tails a prod­uct de­signer mock­ing up each screen of the ap­pli­ca­tion and link­ing each page based on the nav­i­ga­tion.

For ex­am­ple, a dash­board page is de­signed. By click­ing on a graph on that page, it pulls up more spe­cific data that has been used to cre­ate that graph. The ap­pli­ca­tion is­n’t ac­tu­ally built or func­tion­ing, it is a se­ries of screens linked to­gether to give the user a sense of how it will look and feel when built.

There are so many ben­e­fits to start­ing with a hi-fi pro­to­type. It vi­su­ally shows you and the de­vel­op­ment team what will be built. Text is great to an ex­tent — some­times it’s more im­por­tant to see it. It also al­lows the team to con­duct early-stage user test­ing. Start your pro­ject on the right foot with a hi-fi pro­to­type.

1st Level Priority for Service Desk Support

A ser­vice desk is the con­ven­tional way for a prod­uct to be sup­ported. For example, 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. All Product Development pro­jects are pri­ori­tised first for ser­vice desk sup­port, be­fore POC’s and MVP en­gage­ments.

Custom UI

A user in­ter­face is the way through which a user in­ter­acts with an ap­pli­ca­tion or web­site. For ex­am­ple, you lo­gin to Facebook and scroll through the news­feed. Every­thing from the lay­out to the brand colours and de­sign of the news­feed is part of the user in­ter­face.

A cus­tom user in­ter­face gives you flex­i­bil­ity. If you have brand guide­lines or a style kit, your ap­pli­ca­tion can be de­signed to match that style. With this flex­i­bil­ity, you have the power and con­trol to en­sure your ap­pli­ca­tion’s user in­ter­face meets your needs.

Product Backlog

A prod­uct back­log tells your de­vel­op­ment team what will be built. It helps align every stake­holder on what has been built and what is likely to come next. A full prod­uct back­log in­cludes a de­scrip­tion of the fea­ture to be built, along­side im­ple­men­ta­tion steps, ac­cep­tance cri­te­ria and sci­en­tific es­ti­ma­tions.

Acceptance cri­te­ria en­sures that the whole team knows what is ex­pected from every re­quire­ment. For ex­am­ple, this fea­ture is done when a user can cre­ate an ac­count and a record is cre­ated in the data­base.

With a prod­uct back­log you gain the gift of vis­i­bil­ity. You know what has been built, what will be built and how long it will likely take. If for any rea­son de­vel­op­ment must stop, the prod­uct back­log can be picked up by an­other team who un­der­stand the state of the prod­uct.

Manual and Automated Test Plan

Testing is the ul­ti­mate qual­ity con­trol mech­a­nism. Testing comes in two forms, man­ual test plans and au­to­mated test­ing.

A man­ual test plan will en­sure that a de­vel­oper has linked each re­quire­ment to a cor­re­lat­ing test, im­prov­ing the qual­ity of your prod­uct. A key ben­e­fit of the Codebots technology 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.

Don’t be a cow­boy. Benefit from an of­fer­ing that pri­ori­tises qual­ity with thor­ough test­ing plans.


Software es­ti­ma­tions are no­to­ri­ously risky. Because of the com­plex en­vi­ron­ment and the fact that no two pro­jects are the same, it can be dif­fi­cult to know how long a fea­ture will take.

You’ll re­ceive your prod­uct back­log with each re­quire­ment es­ti­mated us­ing a sci­en­tific process that ac­counts for risk, among many other fac­tors. With your es­ti­ma­tions you can bet­ter plan out your roadmap and un­der­stand the trade-off be­tween time/​cost and each fea­ture. If you have a fixed bud­get this can help you pri­ori­tise your back­log to get the most valu­able prod­uct with­out go­ing over bud­get.


A prod­uct roadmap is a vi­sual rep­re­sen­ta­tion of how your prod­uct will evolve over time. This usu­ally in­cludes key mile­stones and the ex­pected date that those mile­stones will be reached.

With a sci­en­tif­i­cally es­ti­mated prod­uct back­log and a deep un­der­stand­ing of your key goals, we pro­vide a pre­lim­i­nary prod­uct roadmap.

This arte­fact is hugely ben­e­fi­cial when com­mu­ni­cat­ing with your in­ter­nal or ex­ter­nal stake­hold­ers about the progress of the ap­pli­ca­tion. The arte­fact clearly shows mar­ket­ing that fea­tures XY are ex­pected in June, while le­gal knows that fea­ture Z is ex­pected in July. While it may change from time to time de­pend­ing on pri­or­i­ties, it is a fan­tas­tic arte­fact when it comes to set­ting ex­pec­ta­tions.

Three months Product Success con­sult­ing

Just be­cause some­thing is built, does­n’t mean it will suc­ceed. 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 prod­uct 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.


A scope is more de­tailed than a work­shop. Where a work­shop is cen­tred around align­ing on the pri­or­i­ties for de­vel­op­ment, a scope goes into much more depth. Because of the ex­tra time avail­able in scope, it pro­vides the prod­uct de­signer with an op­por­tu­nity to test dif­fer­ent de­signs with users and in­cor­po­rate their feed­back into the fi­nal pro­to­type. It also al­lows the de­vel­oper to con­duct a more de­tailed in­ves­ti­ga­tion into com­plex tech­ni­cal re­quire­ments.

This may be true, you might know ex­actly what you want to build. But does the de­vel­op­ment team? Have the users val­i­dated those fea­tures? Have you de­signed and doc­u­mented what it will look like? Have the in­te­gra­tions been in­ves­ti­gated and de-risked? There needs to be time spent at the start of a pro­ject to al­low for this work to be done. If it’s rushed or skipped al­to­gether it poses a ma­jor risk when in de­vel­op­ment. Think about how much harder it is fix­ing a house with bad foun­da­tions vs spend­ing a lit­tle more time to get those foun­da­tions right.

You will have a sci­en­tif­i­cally es­ti­mated back­log at the end of scope. Based on this you can re­view your pro­ject bud­get or re-pri­ori­tise the back­log. It’s im­por­tant to note that they are es­ti­ma­tions and can vary.

No. Estimations are not fixed and by na­ture may change as more is dis­cov­ered. For example, you may de­cide to add a fea­ture in dur­ing de­vel­op­ment which may in turn in­crease the com­plex­ity of ex­ist­ing re­quire­ments.

No. Estimations are not fixed and by na­ture may change as more is dis­cov­ered. For example, you may de­cide to add a fea­ture in dur­ing de­vel­op­ment which may in turn in­crease the com­plex­ity of ex­ist­ing re­quire­ments.

Yes. It is not manda­tory to pro­ceed straight from scope into de­vel­op­ment.

You will be billed fort­nightly in ad­vance on the first Wednesday of the en­gage­ment with 14 day pay­ment terms.

That de­pends. There is no cap on time or cost for prod­uct de­vel­op­ment. You’re able to keep de­vel­op­ing un­til your en­tire back­log is com­pleted (noting the age old say­ing that time is money).

Yes. You can con­tinue to ex­tend de­vel­op­ment as needed.

Yes. I don’t think we need to say any more.

Past Product Developments

How might we de­sign struc­tures faster with­out com­pro­mis­ing qual­ity?

The pre­vi­ous Aptus de­sign sys­tem was not scal­able as a re­sult of its com­plex­ity and its lim­i­ta­tions due to be­ing built on Microsoft Excel. The process of de­sign­ing an Aptus build­ing was known only by the busi­ness owner. In or­der for the busi­ness to scale, Aptus had to cre­ate a scal­able so­lu­tion that could be used by not only other stake­hold­ers within the busi­ness but also by ex­ter­nal or­gan­i­sa­tions. The so­lu­tion was built as a re­spon­sive web ap­pli­ca­tion tar­geted to­wards desk­top users but mo­bile re­spon­sive for users want­ing a quick pre­lim­i­nary de­sign.

How might we cre­ate a web ap­pli­ca­tion for trav­ellers to Moreton Island with a sim­ple book­ing ex­pe­ri­ence?

MIA’s busi­ness op­er­a­tions, es­pe­cially those re­lat­ing to the MICAT (the ferry ser­vice), were be­ing man­aged us­ing out­dated and out­grown tech­nolo­gies that were im­pact­ing MIA’s abil­ity to op­er­ate ef­fi­ciently. The so­lu­tion was a book­ing ap­pli­ca­tion avail­able on web and mo­bile. Part of the com­plex­i­ties of the pro­ject was the de­vel­op­ment of dy­namic pric­ing. What this means is that de­pend­ing on the prox­im­ity to a ferry trip and the num­ber of spaces re­main­ing, the price can fluc­tu­ate within a de­fined thresh­old.

How might we im­prove en­gage­ment be­tween op­er­a­tional teams and res­i­dents?

UniLodge prop­er­ties of­fer stu­dent res­i­dents the op­por­tu­nity to take part in res­i­den­tial events to fos­ter in­clu­sive­ness and a sense of com­mu­nity. However very lit­tle was cap­tured or cen­tralised. Not only was this in­ef­fi­cient, it de­nied man­age­ment the abil­ity to un­der­stand how many events were tak­ing place na­tion­ally in any pe­riod of time. With a large wish list of re­quire­ments, a lengthy scope process was re­quired to un­pack and un­der­stand both the prob­lems to be re­solved and the op­por­tu­ni­ties that were on of­fer. The so­lu­tion was a web plat­form for ad­min­is­tra­tors along­side a mo­bile ap­pli­ca­tion avail­able on iOS and Android for Unilodge res­i­dents.

Apply to start Product Development

Your vi­sion,

our ex­per­tise

Book a strat­egy ses­sion