Pecugate: From Idea to Production Software

In the previous article I claimed that coding is no longer the hard part. Statements like that are cheap as long as you don't demonstrate them on a real project. So here is one: Pecugate, the first project delivered entirely with Claude by Schoeberli AG.

What it is about

Pecugate is portfolio software for Swiss private investors who invest in barrier reverse convertibles. Anyone familiar with these products knows why the software is needed. A BRC is not a security you simply hold in your custody account and whose price you can read off. It has a barrier, a coupon, an observation period, one or several underlyings, an expiry date and a redemption logic that depends on whether the barrier was touched during the term.

Anyone holding five or ten of these products quickly loses track of what the actual risk in the portfolio is. Most investors I know solve this with a spreadsheet they set up once and never quite kept up to date afterwards.

That is exactly where Pecugate comes in: read in term sheets, extract the relevant parameters, assemble the portfolio from them and make visible where you actually stand.

The analysis was the effort

In the previous article I wrote that the real work sits in the business analysis and in the deployment. Pecugate is the proof of that.

The analysis was not demanding because nobody knows how a barrier reverse convertible works. It was demanding because every bank and every issuer structures its term sheet differently. The same information appears once in a table, once in running text, once in a footnote. Barriers are stated sometimes in absolute terms, sometimes as a percentage of the initial value. There is European and American barrier observation, there are autocall mechanisms, there are products with several underlyings where the weakest one counts.

You have to know these cases before you write a single line of code. And you do not learn them by asking an AI, but by laying real term sheets side by side and writing down the differences. That was the part that cost time. Not the programming.

The second part of the analysis was the question of what the software should actually answer. Any spreadsheet can display a portfolio. With BRCs the interesting question is a different one: how close am I to a barrier? What happens to my portfolio if a particular underlying drops by twenty percent? Which coupon is due when? Only once that was clear was it clear what would be built.

The implementation

What I have to say honestly here: the implementation was the unspectacular part. That is precisely the point.

Once the data model was in place – what is a product, what is a position, what is an underlying, how do observations attach to a position – the application took shape at a pace that has nothing to do with classic development any more. Views, calculations, import logic, tests: all things I would previously have estimated in person-weeks and which here simply ran alongside.

One thing mattered that is easily underestimated: I kept checking the results in business terms, not just technically. A barrier calculation that runs through and returns a value is no proof that it is correct. The test is whether it produces the same result on a real term sheet as the calculation done by hand. Nobody can take that check off your hands – and it is the actual value contribution in this model.

The deployment was the second chunk

The moment software runs and the moment it runs in production are two different moments. Between them lie questions that have nothing to do with code.

Where does the data live? With Pecugate we are talking about custody account information belonging to private individuals. That is not a data set you put somewhere because it happens to be convenient. Who has access, how long something is retained, what happens in the event of an outage – those are decisions, not implementation details.

Pecugate runs on Microsoft Azure. That decision was made early, because it means part of the operational questions – certificates, scaling, deployments without downtime – are already solved and do not have to be built individually.

On top of that comes the whole unglamorous remainder: domain, certificates, operations, monitoring, backups, a path for changes without breaking something at the next deployment. None of it is difficult in the sense of intellectually demanding. All of it is work that arises, and nobody does it for you automatically.

Where it got sticky

Three things I would do differently next time.

First: built too early. I started with the term sheet import before the edge cases were fully understood. The result was code that worked cleanly for the standard cases and had to be patched for every second real term sheet. In hindsight, one more day of analysis would have saved several days of rework. That is ironic, because it is exactly what I preach.

Second: the temptation to build everything. When features cost almost nothing, a new problem appears: you build things because you can, not because someone needs them. Every additional feature then has to be operated, maintained and explained. The discipline to say no has become more important in this model, not less.

Third: checking costs time, and you have to plan for it. When implementation shrinks from weeks to hours, the checking does not shrink in the same proportion. Verifying a result in business terms takes exactly as long as before. Anyone who does not plan for that ends up with a lot of software and little certainty.

What I take away from it

Above all, Pecugate confirmed one thing for me: the order is right. First understand, then build, then put into operation and take responsibility for it. The middle part is the smallest one today. The other two have not become smaller.

And the economic effect is there nonetheless. Precisely because implementation weighs so much less, the overall calculation shifts considerably. Where exactly that saving comes from – and where it does not – I will work through properly in one of the next articles.

In the next article we will first clarify a term that is used a great deal and defined rarely: vibe coding. What it really is, and what it is not.

👉 Take a look at Pecugate: www.pecugate.com

Do you have a project that has so far failed on time or budget? Talk to us.