Year One Reflections

At the end of a year it is worthwhile reflecting on what was achieved and whether it has gone as expected. Without this reflection we do not give ourselves the chance to improve next year. Categorica was founded in April 2025 and, a little over one year on, we are sharing what we have learnt from the successes and failures of our first year. Whilst circumstances inevitably differ, there are doubtless common elements; hopefully some of the choices discussed here will prove useful to you.

Structuring “Year One”

Decisions do not exist in a vaccum. The decisions that we made in our first year reflect the economic environment as of 2025 and the available team skills; these are critical inputs into decision making.

Implications of the 2025/26 Economic Background

The period including 1990-2020 was an era of increasing global trade with historically low interest rates and inflation, in a world dominated by one superpower following the collapse of the USSR. The integration of the global economy arguably induced a deflationary effect on Europe and the USA which, perhaps, caused the period of low interest rates as a by-product.

Irrespective of the reasons, monetary dynamics strongly influence the calculus of starting a business. Given a low cost of capital and global markets, the argument for scaling quickly and valuing time to market over efficiency of innovation or implementation is very strong. A low cost-of-carry for debt and the structure of taxation of debt vs equity meant the cost of mistakes in implementation is low where as the benefits of being first and obtaining market dominance are large.

From 2020, the economy appears to have shifted. Firstly, the deflationary effect of the BRICs integrating into the world economy appears to be coming to an end. Secondly, the fragility of global supply chains has been shown up by a pandemic induced inflation shock. Thirdly, increasing competition between larger powers over terms-of-trade which are increasing the risk of entering markets where the regulatory environments are no longer trending towards interchangeability.

Against this economic background, small businesses may find it harder to raise capital and hence will need to manage it more efficiently.

Separately, the business environment is encountering competition from Large-Language-Model based coding. Irrespective of whether they produce adequate code or not, there is a perception in business that they are worth trying and substantial quantities of money committed to doing so by all sizes of company. Whilst LLMs will likely not revolutionise coding as much as their strongest proponents state, they are making CTOs rethink their approach to development. This potentially creates opportunities for software businesses if CTOs come to believe that the LLM technologies fall short on their promise but retain a partial shift towards out-sourcing expertise rather than keeping it in-house.

There appear to be two key takeaway points:

1. A strategy for efficient use of capital to reach profitability early may now be preferable to one of relying on multiple raises based on increasing users whilst unprofitable.
2. A product that requires deep expertise in a subject may be preferable to a more shallow one that is threatened by replication through “vibe-coding”/LLMs.

Founding Team Strengths and Weaknesses

The four of us in the Categorica founding team have worked across software, maths and finance for over five decades combined. During this time we have been fortunate to work across everything from low-level optimisation of code and distributed systems to real-time market data, accounting, derivatives pricing and risk, and e-trading across languages including C++, C, C#, Python and Java.

Whilst our technical knowledge is a strength, we are weaker on product and marketing knowledge having only seen this through internal meetings or when seconded onto sales or support calls.

A-priori we expected to be able to build a technically sound product but that we would have significant learning to do around how to tailor it for customer preferences and, indeed, how to find our product-market fit.

“Year One” Objectives

Given our understanding of the economic environment and our team background led to setting three key objectives;

• Establish solid internal technology and operational systems.
• Produce an MVP that could be shown to friendly, target customers and used to gauge our distance from good product-market fit.
• Obtain funding for a second year in which we could take the strong fundamentals and iterate to good product-market fit and sales; contingent on achieving the first two objectives.

To explain the objectives, consider experimenting with an LLM for coding. Initially it is easy. Code appears very quickly and you can get a simple experiment working in minutes. You then add a feature to the initial request and iterate. The generated application can appear quite good. However, if you look at the underlying code, the amount of change in the previously generated code for that one feature can be concerning. The problem is that where a simple script or application has very few requirements, a production application has many. Amongst these will probably be a list of requirements around concurrent usage, throughput/bandwidth and provable accuracy. These requirements necessitate designing an overall architecture; something that is hard to engineer in retrospectively. Without that design, as more features are added other requirements will gradually breakdown and iteration slows down. The larger problem now becomes apparent; the verbose generated code takes longer to read in order to fix or refactor. Refactoring requires greater knowledge than initially writing the code; the original intent must be understood and alternatives to the implementation considered as well as dealing with the fallout from errors caused by a lack of testing or, even more problematic, user dependency on buggy behaviour that they will object to seeing removed.

Experience suggests that it is easier to avoid problems by designing a system so that they cannot occur than by attempting to solve problems in a system that already has them. As a software company, your build and test environment cannot be an afterthought. If it is costly in time and resources to iterate you will do it less. As finding product-market fit will inevitably involve some experimentation this needs to be cheap. Consequently, building solid internal technology and operational systems is logically inextricably bound up with producing getting to market fit for your MVP; you will need to iterate without becoming trapped by technical debt. High-quality systems are how you achieve that; for a software company they are your competitive edge.

Solid Internal Infrastructure

Given these objectives, the objectives were broken down to the following logical sections:

• Internal Systems
  • Finance
  • Security and Disaster Recovery
  • Hardware and Hosting
  • Programming Language of Choice
  • Build and Test Environment
  • Deployment
  • Human Resources
• The MVP
  • Product
  • Marketing and Sales

Internal Systems

In building our internal systems we chose to apply various design principles, influenced by software design:

• Comprehensive Versioning
  • All documents should be stored in access controlled, versioned storage such as Git.
  • Independent of company function or document purpose, versioning uniquely defines who has access, what the latest version is and provides an auditable record of changes to it.
  • Versioning simplifies the creation of a future company information hub from that single source of truth.
  • Adherence to DevOps principles; versioning infrastructure as code, testability and security bring dividends in speed of iteration from day one.
• Security
  • The master credentials are encrypted and are pulled from the encrypted vault automatically given appropriate permissions.
  • Different purposes require different groups and accounts. There is no reusing of an account for, e.g., build and deployment or finance and HR.
  • Whilst this might appear to be an unnecessary step that over-complicates setup it establishes something that is otherwise hard to add later. Currently we have limited role segmentation to Admin/HR, Finance and Technology (Code/Infrastructure) though further differentiation is now trivial to add in the future.
    • Access control is simply a matter of not granting new employees access to all groups or removing it from someone if they do not need it later as roles evolve.
    • Best practice for password management, e.g. rotating passwords, means writing a script that can update those passwords in the single source of truth.
• Componentisation: Layered Design and Testing
  • There is a cost to where problems manifest; it is more costly the further down the pipeline they are.
  • To avoid problems manifesting for users, the more that whole categories of problem can be made unrepresentable the better.
• Carefully Select for Build vs Buy vs “Wait”
  • Whilst there are some excellent SaaS products, they are often not cheap in aggregate. Whilst a £10 cost per user per month does not seem too high, the cognitive load of managing the systems, billing and interop between them should be considered in addition to the long-term questions around cost of migration if they prove unsuitable. The costs also add up.
  • How people work as a team changes as the team size does. You do not need to solve the problems of a 100 person company when there are 2 people.

Finance

The finance functions informs all your available choices. The minimum requirements were:

• Bank Account.
  • Enable receiving invoices and paying bills
• Revenue Receiving Mechanism
  • Not strictly required for B2B.
  • For B2C an interface to a trusted intermediary, e.g. Stripe, for reducing the barrier to being trusted by customers is required although the per-transaction fee is not negigible.
• Accounting
  • Books/Records Platform (e.g. FreeAgent)
  • VAT Registration

Separately, both for accurate record keeping and with prior experience of requirements for the UK year end, we also chose to

• keep accurate records of time spent on research
• file for reduced national insurance contributions
• apply for SEIS/EIS advance assurance
• add all invoices and receipts to version control

Although the record keeping is not overhead free, it is useful in maximising the chance to reduce the running costs that are expensive for small, research intensive business and to meet expectations for investors into small, high-risk companies. There is a separate benefit in that disciplined record keeping naturally aggregates much of the information that prospective investors can ask for.

Security, Disaster Recovery and Customer Data.

It is presumably not controversial to state that security and disaster recovery are key components to a successful software/service business. No matter how great the software product, a poorly executed update to networking or database schema, a leak of customer data or security event can destroy trust in it leading to loss of sales and potentially even legal ramifications. At the minimum system downtime will slow delivery of, and innovation into, your product.

Fortunately, for an early stage company, there are significant mitigations in place purely by virtue of the lack of size.

• Our most important asset, the codebase, is naturally backed up through its distributions across the teams’ laptops. A periodic remote backup was added after about six months.
• Customer data is initially small in size. Backing up an encrypted and compressed few TBs of data to online backup is very cheap (e.g. ~$7/month up to 3TB from European GDPR compliant vendors.)

Note that the ease of backing up either a database or a code repository to secure and encrypted, offsite storage is a key reason for treating everything like code, in so far as is possible. The finance or HR repositories can be backed up in the same way up to a different encryption key/password. Although we chose to manage or build much of our infrastructure ourselves, our VPN and password management are two areas that are critical that, as we are not cryptographic experts, we have chosen to buy. Security is arguably an area you must either be world class at or depend on a product that is.

In discussing security it is also necessary to consider who your customers are likely to be. For instance, in the UK/EU where GDPR will be of concern, ensuring that the storage of your data complies is important. Again, versioning and segementation of the data is important as, given a locale tag, backup or storage can be directed when the system is designed with this in mind from the beginning.

Although storing some information about customers is required we have chosen to minimise the amount that we do hold to the extent that we can. Although some kind of customer number is needed as linkage, using an external authentication provider, e.g. Auth0 for credential management and linking that to a payments provider via a common id ensures your systems never see the data that could be compromising. Although some customer information will be useful in order to tailor products and services, not holding that until you have a dedicated security team reduces risk here.

Hardware and Hosting

Perhaps the key choice for service provision is whether to design for the cloud first or in addition to a local deployment. This decision was made by reference to both cost and the development process.

Firstly, consider the costs. Cost calculators can be found for all the major cloud providers, e.g. https://calculator.aws/#/ . For a single mid-spec server, the yearly costs are just under $6,000 as of April 2026. These break down to

Service.	Instance Type	Cost per Month in $
EC2 Compute. vCPU:8, 16GB Memory	Shared	$130
Postgres, (db.r6g.large0 (16GB Memory, 1TB storage, vCPU:2))	On-Demand	$365

Our experience suggests that these estimated costs are often conservative; they typically under-estimate in network traffic in intra-cluster communication, or over-estimate the capabilities of a deployed service. Intuition indicates that CSPs need to purchase, run and manage infrastructure, including an additional overhead of a - principally adverserial - multi-tenanted environment, whilst also generating profit; it is surely possible to do the same for less.

Consequently we have opted to manage our own bare metal infrastructure. Whilst setup a cost this has been a moderate up-front one for us with minimal day-to-day overhead. This gives us full ownership of our data whilst removal initial worries of spikes in dynamic fees that might be incurred in a cloud-first environment.

Secondly, for development, optimisation and support it is useful to be able to replicate everything locally. In our judgement, it is easier to design a system locally to allow for Docker containerisation and deployment to the cloud later than vice-versa. Consequently we have minimised container usage to creating an isolated environment for integration testing in the CI/QA environments.

The efficiency of design is worth obsessing over early; it becomes increasingly hard to achieve it as time passes. As the numbers of developers and product managers increase, discussions and communication starts to dominate development time and coordination of substantive change becomes both error prone and difficult to achieve as the number of people who understand the full system dwindle.

Programming Language

Having had substantial experience in C++ we have opted to use that in our systems for two specific primary reasons. Firstly, we have individually spent over a decade each with it. Secondly, the templating and compile-runtime compute switching capabilities introduced in C++ standard 17/20/23/26 are probably indispensable to what we are building.

Although secondary to that, we have also observed that coordinating many developers is harder than coordinating a few and that investing in training developers is worthwhile but also expensive and time consuming. Given our estimate that efficient use of resources is becoming more critical in the current business environment we intend to grow personnel more slowly and so, whilst we recognise that C# or Python would make hiring easier, we think that the tradeoff is worth paying at present.

Build and Test Environment

We designed our product to be built, tested and deployed cross-platform on macOS, Windows and Linux. This is probably where the choice to use C++ might be most easily regretted as it does mean occasional cross-platform differences in implementations that would generally not exist if we had chosen Java or Python. However, apart from a few platform dependent differences from different implementations of some numeric libraries (e.g. random: Mersenne-Twister between Windows and Linux), the cost has been low to date and performance is considerably better.

The pipeline that builds, tests and deploys the packages uses Concourse as an orchestrator. Using our own hardware it is possible to use pre-packaged scripts to separate jobs out to run under the credentials of specific users with permissions appropriate to a single or small number of tasks, thereby removing the dangers of a compromised Concourse or Kubernetes “God” account.

>

Deployment

For now, we have opted to package our server-side software with native packaging tools. This has allowed us to avoid any lock in with containerisation/virtualisation approaches, although we still use Docker in the context of testing (specifically in more integration-oriented test set ups). We’ve tried to remain agnostic on specific deployment technologies to allow flexibility for other use-cases.

For our internal infrastructure we have simply used Ansible to version and deploy. This is probably one area that we are not entirely happy with; this is nothing against Ansible but that we have noticed that what we really wanted was a fully versioned environment down to the operating system and other packages on which our deployment depends. Whilst we have no plans to do this at present, Nix might have been a good alternative to migrate to or to start with.

HR

With a very small team, HR has not played a big part for us beyond the legal requirements for a UK company around salary and pensions. However, we have applied a few software principles to it: everything is versioned and we have looked to use our internal database to verify our permissioning and IAMs. As we have the UK GDPR requirements it is an incentive for us to get that right and a useful testing ground for dog-fooding our other work.

The MVP

Our team has a background that is primarily maths, software and finance. Consequently whilst we strongly believe that product and marketing matter, indeed a business that doesn’t care about that and hence its customers is clearly not going to survive, they are not things we think we are naturally good at.

These areas are perhaps the ultimate core of any business; a business survives by providing useful and enjoyable products for its customers rather than just being a great place to work. How one reconciles these related aims is perhaps at the heart of product and why it ends up being such an important nexus for a company. Given the unique nature of a company, perhaps how one does this is the hardest part to describe and least useful to copy.

In any case, having not had responsibility for these areas before, we have perhaps an unusual take on them. We hope you find this interesting or, alternatively, amusing.

Product

Given our previous experience in finance we had a strong initial direction on what we wanted to build; an analytics application for bonds and stocks that could go into significantly more detail than those that we could find in retail software or had seen in that we had worked on. We believe, and wish to prove, that financial products can be analysed far more accurately than people are currently doing.

Equally, having noticed that as a product progresses thoughts on what can be done with what now exists arise, we wished to build this product in a way that would allow those to be added without necessitating a full redesign.

In 2025/26 we have iterated on our MVP ourselves and seen it in use by a few trial customers. Feedback indicates that the functionality is useful but that the initial functional API was deterring casual users for whom a GUI or Excel were preferred, or that our coverage of instruments was still too sparse. Whilst we have not had the explosive take up in usage that startups dream of, glimmers of excitement from users gives us reason to be cautiously optimistic. As we fix the remaining gaps, we hope that we are closing in on the point at which we have matched a target audience and can then focus marketing to it.

Marketing and Sales

To date we have spent little time on marketing nor on direct sales beyond reading widely about it. We believe that we need to, and to some extent think that we can, answer three key questions

• What challenges do our prospective customers have?
• What challenges will our prospective customers pay to solve?
• What is the actual challenge a customer wants to solve, as opposed to the challenge that they describe?

Our expectation is that as we close in on product-market fit and customer uptake increases, we can close the loop between what we think the market wants, what we are building and what customers actually want to buy in this space.

In conclusion

Wherever we have worked, from large corporates to small startups and SMEs, it is somehow still a surprise to look back at the end of the year and simultaneously think how much we did and how little progress we have made. This year has not been an exception. There has been lots to do, learn, be happy with and look forward to. We hope to see how people will use what we have built in practice, and hope that what we have designed is (mostly) how it is used.