a for agile

We are devoted to helping people learn, think, and create better.

We endeavour to record, study, and promote their living heritage and identity. We undertake research on the functions and values of their cultural expressions and practices.

We develop solutions to ease them through our times.

d for development

We create digital products, provide UX design services and organise industry events and workshops.

We work across business, technical, visual and marketing levels, to ensure that the final product experience does not degrade because of politics, budgets and strong personalities.

We think hard and play even harder, not only from a design perspective, but on project management and engineering aspects, mitigating risk for you (and us).

ax for analogue

em for digital

moving your b2b app to the web


Multi-tenancy needs to be built into all layers of your application, including the UI, the business logic and the database. Multi-tenancy requires that code execution from one customer is isolated from another and customer-specific resources are protected. Data from each customer can either be stored in a different database (least efficient), different table sets, or data can be mixed together in a single database and virtually partitioned (most efficient).


Your customers will need functionality to allow their own customers to access your application. Your customers’ customers will authenticate against your application to login, with restricted access to various application areas according to their roles and authorisation levels. More granular security, although mission-critical for some b2b markets, offers little strategic value and requires disproportionate amounts of debugging time.


To properly test new functionality, you will need to deploy to a sandbox that mirrors your production environment. You will also benefit from a clearly defined process to transition accepted changes from the sandbox to your production environment. The capital investment costs for multiple infrastructures (production, testing and auxiliary) must be factored into the overall project budget.


To deploy new functionality and bug fixes with zero or minimal downtime, your application will have to support the absorption of new releases on the fly. Similarly, your SaaS infrastructure may require the use of cutover techniques that allow new releases to be running in parallel with old code, dynamically re-routing your customers to the newly deployed version.


As your application is moved to the web, your existing customers (the people that brought you where you are today) will be upgrading sooner or later. Code should be written and extensively tested to migrate their precious data to the new architecture, handling all exceptions (new functionality added or old functionality removed) with care. This subproject alone is equivalent in size to the main web application development task.


New customers will gain access to your application by subscribing online, instead of using traditional direct or channel sales. Your application will require a mechanism to seamlessly create an account for the new customer, execute all on-boarding workflows, setup network resources on your (or your outsourced) infrastructure, and grant access to the application. Never underestimate how a poorly executed web application sign-up can affect your bottom line: dropouts (drop-offs in SEO sprache) rarely come back…

Comments are closed.