How to Build Tax Web Applications
Do you see a business case for a tax technology tool that automates a specific workflow? This post lays out a development life cycle and offers insights into each stage of your project. In particular, our learnings are inferred from building web applications that digitalize workflows in the corporate tax world (hence tax web apps). Web apps are software applications that don’t need to be downloaded or installed but are accessible through a web browser with an active internet connection.
With today’s tools and libraries for developing web apps anyone can build and own a digital solution irrespective of know-how and resources at hand. Aside from reaping the benefits from solving one’s own automation issue and reducing in-house technology debt you may also want to share freemium versions of your tool for marketing purposes or monetize the tool on a platform ecosystem.
Illustration 1 shows each stage of the development life cycle listing key activities, assets, tools, and learnings. The content is a selection of favorite resources and practical insights covering items relevant to product owners from the business side. [1]
The stages Ideation and Design can be completed each in under 4 weeks depending on tax subject matter expertise, prior experience, and familiarity with tools (e.g. writing requirements specifications and prototyping). The development stage for a first version of a web app with enough functionalities to achieve a level of automation worth the money and resources spent can be 12 weeks depending on the expertise of the engineering team and the quality of technical specifications.
There are certain factors unlocking innovation. For example, put together teams with individuals having expertise in more than one area or ensure that teams work well together with complementary skills. Innovation often happens at the intersection of domain knowledge areas.
The question of in-sourcing versus out-sourcing can seem daunting at first but should not drive the decision whether to build something or not. Smaller organizations have the option to complete certain stages by themselves, together with a team within the same organization, or outsource to contractors or partners. For most entrepreneurs coming from the business side the only tasks to worry about initially are within the Ideation and Design stages and relate to how well ideas can be handed-off as technical specifications. A beneficial partnership is often found through numerous conversations discussing specifics down to a painfully granular level.
When mapping out your work plan consider the stages below.
Ideation Stage
Start with a problem statement, a business use case quantifying the impact, or in simple words what you want to solve and what value it brings to the customer. You can use a bottom up approach to quantify the business impact of specific functionalities. Value is often delivered through better control of processes, automation of redundant tasks, collaboration between team members, data validation, a single source of truth, structulized data, etc. The results impact time, quality, or scope of workflows.
Whether to build something or not depends on alternative ideas on your roadmap, assessment of probability of success, and your risk versus reward preference. Former two factors are your project’s opportunity costs. Projects exceeding opportunity costs the most are promising ones.
Design Stage
Next, memorialize the content from the ideation stage and translate the functionalities into product features extending the general description and purpose of the features with illustrative user stories, user interface sketches, and detailed user requirements. This is the requirements specification documentthat will be the blueprint connecting business and engineering and will be the most important document to define, understand, and prioritize the build of the product throughout the development life cycle.
The more specific you are with user stories, sketches, and requirements the more back-and-forth communication, scrapping and starting over again you will avoid. The best way to achieve this is to prepare detailed sketches of every step within the digital solution you are creating. By taking it as far as you possibly can the designer is forced to fully understand the features and rule out time consuming paths taken during the implementation stage. To increase the quality of the requirements specification document do the following:
- Learn to use a prototyping editor such as Figma and create a design system to speed up the preparation of sketches.
- Based on business logic of the problem at hand create a library of user interface elements such as input tables and data controls.
- Create high-fidelity sketches with the editor.
- Inquire from the engineers what questions should be answered when drafting the specifications for the prepared sketches and answer all of these in a structured way.
- Prototype no-code parts of the solution already in the design stage such as the build of analytics dashboards with BI software from dummy data.
- Prepare any other materials that get the functionalities, web app input and outputs, look and feel, etc. across.
The business logic should drive which parameters data tables have, in which order data is inputted, how the data is structured into data points, how data is mapped to each other, etc. It is not a prerequesite to map out a data model as this can be done by the engineers, however, being able to explain the data structure in simple terms will speed up the work of the engineering team considerably.
Common user interface elements of a web app include:
Dynamic rules can be added to specify the interdependence of web app content with the possibility of varying user flows based on paths taken.
Ultimately, user interface elements and the back-end infrastructure that will be build in the implementation stage will make up the desired features of the web app. Features can be the related to team collaboration, data transformation and storage, data input handling, data and content output generation, etc.
High-quality prototyping enables the designer to learn about the product without actually having to build and launch it. If the prototype is not convincing enough changes can be made within the Ideation or Design stage with no resources spent on building and implementing the product.[2]
Development Stage
Once you enter the development stage the roadmap and processes can be managed well with tools such as Azure DevOps. For example, in Azure DevOps terminology, translate your findings from the ideation stage into epics, the functionalities into features, and let the engineers reign in structuring backlog items and tasks. The initial setup of the aforementioned requirements definitions in DevOps can also be done by a product manager or an engineer with business background. The timeline, potential unknowns of the project, and the required flexibility will determine which approach to software development is taken with agile or waterfall methodology being the most prominent ones.
Software engineers will likely distribute tasks according to front end and back end items and will ensure the proper set up of the data base, server architecture, security measures, etc. As certain elements of the solution are being completed the business side will be involved in software verification and validation to assist the engineers in achieving the desired functionality and business impact by the solution being developed.
There are certain software architectural aspects which if tackeled by the business side and not left to engineers only can bring certain benefits. The reason is that after implementation the options to involve or hire engineers to improve the product can be limited. At the same time the business side might want to make changes rapidly without involving engineering. Therefore, move certain value-adding aspects of the solution to low or no-code parts of the solution that are accessible to non-engineers. An example would be to move data calculations from the back-end to a BI platform.
Another workflow related aspect where the business side can contribute is determining the order and scope of the elements of the solution to be completed and tested first. The shipping of the solution in small increments ensures consistent progress and helps prioritize. To meet development objectives during busy work phases business and engineering may collectively decide on and adjust quality, timeline, and scope of the shipments. Constantly re-evaluating impact versus effort helps in prioritizing and weighting elements to make the most of engineering resources.
An important characteristic to consider when building web apps for the tax world is that there is a layer of tax domain knowledge required in each stage of the development life cycle. Domain experts should therefore demystify tax for the rest of the team, do much of the pre-work in translating vague tax law or tax operational workflows into commonly understood schemas and processes, and prepare requirements specification documentation that leave no room for interpretation of the objectives.
Operation Stage
Once the first version of the web app is up and running and first customers pilot the app it is time to collect customer feedback based on extensive usage of the app in the production environment. Customer requests for enhancements and new feature requests are then evaluated and added to the product roadmap of features that were left out when building the first version of the app.
In case the updated roadmap contains a large number of possible request for which resources are scarce there are methodologies assisting in the decision making process. One of these is the RICE methodology whereby items to work on are ranked based on quantifying product Reach, Impact, and Confidence in your estimation and then dividing by the development Effort needed.[3]
Ecosystem Landscape
A last few thoughts are spent on how to choose the right ecosystem landscape for your web app. Being part of an ecosystem brings various advantages. Web applications built for tax analysis purposes and aimed for distribution can especially benefit from two factors: How mature a platform ecosystem is and how detailed and comprehensive the underlying data model and data taxonomy is. The former will help you in reaching a broader audience in the market while the latter will improve the quality of your product by building on top of a common data framework, i.e. enabling the ecosystem and web app to speak the same language.
As an example, building a web app in the field of transfer pricing (a subfield of international taxation) the ecosystem landscape looks as in Illustration 2.
Choosing an ecosystem platform can also be of help if instead of being made for distribution the web app stays exclusively in-house. As there is a wide network of solution builders and a higher degree of building activity finding partners and leveraging of existing code and libraries reduces the effort needed to build your solution.
Sources:
[1] Input based on a comparison of life cycle models used by high-tech commercial integrators, NASA, US department of Energy and others, see INCOSE (International Council on Systems Engineering) Systems Engineering Handbook — A Guide for System Life Cycle Processes and Activities (2015), John Wiley and Sons, Inc.
[2] Based on learnings from Google Ventures’ design sprint process, see https://www.gv.com/sprint/
[3] Intercom pioneered RICE roadmap prioritization model, see https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
Join “Technology for Lunch” Live Event in Zurich on June 10th 2022 on How Everyone Can Build Tax Web Apps and Sign up for AIBIDIA Studio
About the author:
Max Stobbe worked on transfer pricing documentation and planning for Silicon Valley-based multinationals and today designs custom web applications for Europe’s most innovative tax departments.
