Advyzon’s biggest differentiator — the thing that makes us truly special — is our comprehensive approach to technology and development. We were one of the first companies to listen to advisors that said they wanted less software and fewer programs … but still needed all the tools they had come to depend on. Rather than try and stitch together multiple programs in a tech stack using integrations, Advyzon was built on the idea that advisors deserved a holistic solution. That means that, whenever possible, we develop new features in-house.
Why? Because even the smoothest integrations require some form of middleman. And that creates a limited user experience that can make life harder for advisors (i.e., endless toggling between windows). We’ve written about our approach to partnerships and integration, and in this article, we want to focus on the other side of that coin: how we develop new features and technologies internally at Advyzon.
When it comes to developing new programs and technologies, there are three main components: backend technology, frontend interface, and subject matter expertise. Let’s dive into each of these a little bit more.
- Backend technology is the part of software that users have the least familiarity with. Essentially, it’s what powers any type of web-based technology. Think of it like the piping in a building — it delivers critical services in an efficient way … but it works best when you don’t have to think about it or see it. This is also where the databases, servers, and frameworks for integration live. A strong backend is essential for building a product that works well. After all, even the most beautiful building would lose its appeal if it didn’t have working bathrooms.
- Frontend interface is more commonly known as user experience (UX) or product design. This is the part of a program, app, or technology that you interact with. A good interface or design is intuitive, or easy to use. Developing technology in-house helps us control UX and make it as easy as possible to move from reports to rebalancing in just a few clicks.
- Subject matter expertise is particularly important in specialized markets, like creating technology for financial advisors. To build a rebalancer, for instance, you not only have to be versed in coding on the backend and user experience on the frontend … you also have to understand what goes into asset allocation (including target allocation, tolerance bands, and security sets) and how to deliver trades to custodians.
This third piece is one of the most critical components to developing new technology. Most financial technology, or FinTech, companies have developers and designers on staff. But to develop a new and specialized tool, firms may need to search for and hire new team members. After all, this expertise is critical to both the backend code and the frontend experience. But anyone who’s had to manage hiring or firing at a company knows that finding this kind of talent can be easier said than done; it’s one of the main reasons large firms will eschew in-house development in favor of simply acquiring new tech from someone who’s already figured it out.
In 2020, the world learned just how many steps go into developing a vaccine. The same is true of new technology. First, you need to assess the project or determine its scope. In business speak, we gather requirements and use cases. Or, in simpler terms, we outline what the technology needs to do.
Next, we design the framework and UX — what we want the new technology to look like and how we want it to work. That allows us to create a plan. This includes how we’ll build, implement, and test the next technology. Once our internal team is happy with the test results and how the product is performing internally, it moves into beta testing.
With beta testing, we ask a handful of trusted clients to begin using the new tool or technology. This allows us to evaluate how a product performs in the real world, but with a small sampling. Often, situations come up that we may not have been able to predict in controlled internal testing, and we’re able to see how the product performs in those situations on a small scale. While we never ask advisors to test anything that we aren’t fully confident in, we prefer testing products with a smaller sample size.
The other option employed by developers is to rush a technology to market, then fix any bugs or glitches in future versions. This may make sense for consumer-facing products, but we don’t think it works when there’s sensitive information and money on the line.
We should note that beta testing is limited to larger projects; with smaller rollouts, we create weekly milestones that allow us to respond quickly to user feedback and continuously improve new features.
Let’s consider how this approach to development works using a real example — our new Quantum Rebalancer. We’ve wanted to work on developing a rebalancer for years; we know how important rebalancing is to both performance and risk management, and we wanted to remove any middlemen and give our advisors an in-house option.
Still, knowing we wanted to do it and finding the right team to execute that idea are two different things. We finally got everything in place in 2020 and began development. By mid-2021, we were in beta testing. For more than six months, we asked advisors to use Quantum and to share their feedback along the way. By running the beta test for more than two quarters, we were able to work with these advisors through two periods of rebalancing before rolling the product out to our broader clientele.
Curious to see all of that work in action? Set up a Quantum demo today.