Tomorrow morning, I start UpRise at Upvest. I am in Berlin for onboarding this week before returning to London, where I am based.
I have been looking forward to writing that sentence for a long time. I already shared the career update. This note is about why the move matters to me.
The shortest answer is a principle I came to believe while working on financial systems:
Simplicity is not the absence of complexity. It is complexity somebody has agreed to own.
Upvest’s mission is to make investing as easy as spending money. What interests me is the engineering responsibility hidden inside “easy”. A clean investment experience still rests on systems across brokerage, settlement and custody that must remain understandable when something leaves the happy path.
Upvest chose to build at that layer. That is where I want to learn.
The work behind a simple interface
For a client, one API can be the surface. Underneath it, Upvest publicly describes systems spanning brokerage, settlement and custody, with financial state changing asynchronously and services synchronising through events.
The interface becomes simple because the complexity is being handled, not because it disappeared.
That is what attracts me to infrastructure. Done well, it expands what other product teams can build. It lets them focus on the experience they want to give their users while deeper infrastructure carries much of the financial and operational work underneath.
Those technical choices reach two audiences. Upvest serves clients whose products, in turn, serve end investors. A change has to work for both: the integration must be clear and useful for the client, and the outcome dependable for the person using the product.
Five years from now
From the outside, I do not think the interesting five-year question is simply how many clients or products Upvest adds. It is whether the company can make institutional change safe and repeatable.
The public plans with DKB and Plum point in that direction. They include moving established investment businesses and operating relationships, not only launching greenfield products. That can mean moving data and workflows, and reallocating operational responsibilities under local rules, while end users expect continuity.
If that capability compounds, I can imagine Upvest becoming a programmable layer behind a wider range of European investment experiences, making a new market or product less like rebuilding the entire stack.
AI adds another reason. A 2026 FCA review says AI could reshape consumer journeys by 2030. If advice and portfolio intent become more personalised and frequent, generating an idea may become cheap; acting on it responsibly will not. The harder asset will be infrastructure that carries intent into a financial state that remains correct, observable, and reconcilable.
That future is not guaranteed. It depends on migrations surviving scale, localisation becoming reusable rather than bespoke, meeting institutional and regulatory standards, and AI increasing delivery speed without weakening human understanding. This is an outside-in view, not a company forecast. It is a future I find credible, and one I would be proud to help build.
Where my own work has been pointing
My route here has moved through AI, optimisation research, internal agentic workflows, and financial data reconciliation. Those areas look different, but they kept teaching me versions of the same lesson.
Outside work, I enjoy following stock-market updates and the companies behind them. I have not invested in stocks yet, but I would like to start. I often first notice a fundraising round or IPO on X, then read further into the business and the decisions around it. Investment infrastructure feels personally relevant because it sits where that market activity becomes software, operations, and recorded ownership.
At Lendable, I saw the leverage that a useful internal AI workflow can create. I also spent much of my time reconciling financial records into a canonical view and building monitoring around it. That work made the less glamorous half of automation impossible to ignore. Before a system can act intelligently, somebody has to establish what state it is acting on and how that state can be trusted.
Optimisation taught me the same lesson from another direction. A solver can be exactly right about the model it receives while the model is wrong about the product outcome people actually value.
These experiences left me returning to one question: how does an intelligent decision become a reliable system outcome? It became the theme of this site. At Upvest, that question becomes production work.
During my interviews, I kept returning to Building with AI at Upvest. What stayed with me was not a token budget or a number of agents. It was where engineering judgement moved once producing code became cheaper: towards understanding the client problem, deciding what should be built, validating correctness, and proving a change is safe to ship.
The shared toolkit makes useful AI work reusable, while the authenticated MCP Gateway governs access to approved internal systems. Deterministic tests and the human who understands and approves the change remain the trust layer. That is the AI-native engineering model I want to practise: use agents wherever they improve the work, but never use them to hide weak understanding.
What I want to earn this year
UpRise is structured around immersion, ownership of a difficult technical challenge, and time embedded in a core engineering team. I am excited to deepen my Go and product engineering skills in that environment. Collecting technologies, however, is not the outcome I care about.
I want to learn how a client problem becomes a safe production change, how that change behaves after release, and how the team knows whether it achieved the intended result. That means understanding the investment lifecycle behind the API, not only the shape of its endpoints.
Public documentation has given me orientation. It has not given me first-hand knowledge of how Upvest’s internal systems are built and operated, and preparation is not performance. Production Go fluency, investment-domain depth, operational judgement, and trust from a team are things I still need to earn.
What I bring is a way of working. I make the outcome and assumptions explicit, use AI for bounded leverage, and test the resulting claims. I care about lineage and reconciliation, and I write down the reasoning so somebody else can challenge it. Those are useful starting habits. Their value here will depend on what I do with them.
Tomorrow is for onboarding, listening, and learning. As I begin contributing in the weeks that follow, I want to ask precise questions, ship small and reviewable changes, seek candid feedback early, and follow the work beyond the merge. If I find an AI workflow that helps, I want to understand the need well enough to make the improvement useful to other people, not merely impressive in a demo.
I do not expect to know the answers on day one. I do expect to care about the outcome, learn quickly, and make the work easier for the people around me.
The opportunity is here. Now I have to earn the rest.