Why fintech and why Xelix?

Hello! I’m Nikhil a Frontend Engineer here at Xelix. I’ve been here for just under a year but before that I worked at a Big Blue billion dollar tech company. I joined that company straight out of university and found myself in the midst of some very clever people that I could learn a lot from, and that’s exactly what I did. I started off as an support engineer, so I had the opportunity to get my hands dirty with a lot of different technologies but I really liked working on the frontend using React.

Eventually I used my React skills to work on a rare greenfield project building a visual modelling tool, which is where I first got a taste for the startup sort of environment. We were building the product very quickly with a lot of trust being placed in engineer’s decisions, releasing often and showcasing our work to shareholders at regular intervals. I loved it! I was given the freedom to take chances, fail fast and learn from my experiments. Eventually, I was ready for a new challenge and a chance to keep growing, which is when I found Xelix.

Xelix stood out as a growing startup with ambitious plans to scale. It moved quickly, shipped often to get feedback, and course corrected to build the right thing. All the elements I liked in my previous position. Most importantly, it was full of the kind of clever people I started my career in the midst of. My last role was also fully remote, and I wanted to learn from people like that in person, in a team I'd see every week and get along with as much as I learned from. Fintech offered a challenge at the opposite end of the scale to what I was used to - complex financial data arriving every day and every hour with high stakes, compared to the slow cycle of methodical approvals and checks that I was used to in systems modelling. Xelix’s combination of environment, culture and this new domain made me jump at the chance to apply.

The frontend problems fintech has

Fintech is all about continuously streaming high volumes of financial data quickly, because delay costs money. At Xelix, we handle invoices coming through every day at all hours; this poses some interesting frontend challenges.

Large volumes of data like this lends itself to display in a tabular format, which must have lightning fast sorting and filtering. Then there are the other challenges of fetching the data, rendering all of it to the page efficiently and catering for users’ custom views so they only see the data that is relevant to them.

Even when we have all the data however, it doesn’t stay static. I work on the AP Automation module, where invoices move through workflows and their states change. That creates some demanding frontend challenges: keeping the pages and tables that display invoices up to date efficiently, making sure updates don’t disrupt actions users are already taking, and giving users clear, accurate guidance when conflicts or errors occur. Handling those situations well is essential to maintaining trust in the system.

These are just some of the hard frontend problems that we face in fintech, and Xelix in particular. The range of problems is what keeps the work interesting, and it all comes from a corner of finance that few people think about.

Why accounts payable?

Before Xelix I had little idea about Accounts Payable apart from what my accountant housemate told me: it was boring, monotonous and he “would never go back to doing it”. The repetitive, document-heavy, rule-driven nature of AP might be some people’s version of hell, but to me it’s exactly what makes it ripe for automation and AI to revolutionise. And because few engineers choose to work in this space, there’s real room to make a difference.

Xelix’s goal is to transform AP from an unsexy cost centre into a strategic source of value. It’s an ambitious goal, and the new edge cases, workflows and integrations that crop up daily mean there’s no shortage of challenges for me as a frontend engineer. And we get plenty of freedom for how we solve them.

What FE ownership looks like at Xelix

Xelix organise the tech side of the company into squads. There are between 3-10 members and they consist of some frontend engineers, some backend engineers, a designer, product manager and one of the engineers is also a squad lead. This combination of designer, PM and squad lead are the trio who are the ones involved in moulding the roadmap, organising the team and making high level decisions on how the product should work.

Once feature work is ready for engineers, frontenders get the autonomy for how that work is split up, distributed and ultimately implemented and have discretion to organise our work however makes most sense for us. This also means we have complete ownership of features so when they work really well, both the satisfaction and the credit is direct.

Ownership also shapes how we start. Before building anything, we kick off with design and product to understand what’s the smallest thing we can build to get feedback on this feature as soon as possible. That often means descoping or simplifying the designs, knowing they’ll be improved once our theories are confirmed. It’s the same approach that drew me to Xelix: ship early, learn from real users and course-correct to build the right thing. It’s also what makes me excited about what we build next.

What I want to build here

In the near term, I want to improve our AI integrations within the platform. We already have an incredible foundation of manual and automated flows, and the next stage is to continue to use AI to make them even simpler. Xelix's aim is to bridge the gap between how people think about their AP processes and how technology, particularly AI, can support them. I want to play my part in making that vision a reality.

I also want to continue building on myself as an engineer. I’ll use the extensive support avenues we have at Xelix to continue deepening my knowledge of the React ecosystem, and extend my “T-shaped” skills into our backend Python systems so that I have a more holistic understanding of the platform.

Above all, I joined Xelix to build quality software that’s a joy to use, and to help design flows that are easy to use, understandable and reliable. Ultimately, I want to make a positive difference for AP clerks like my housemate used to be, who hated the repetitive, boring nature of the role, and help to shift that perception.