SegTax Technical Foundations

Background

The primary technical challenge of automating cost segregation is building up the inventory of assets associated with a given property. 3D scanning, satellite mapping, machine learning and large language models can be combined in novel ways to tackle this - but before we get there we had to move the back office work of cost segregation that currently takes place in Microsoft Excel and Word into a web deployed application backed by a relational database.

Segregator Web App

The Segregator is a full stack Kotlin web application built for enterprise scale, security and reliability. I am using a common pattern of splitting the application into discrete layers.

All in on Kotlin

Kotlin is a safe and modern language, especially when used with immutable data flow. Immutable data flow works best when it’s baked into the design of the database schema. By limiting updates and focusing on writing and deleting, we can avoid side effects and nullability issues. Kotlin also has null safety built into the language at the compiler level.

Kotlin for the Front End – Server Side Rendering

I decided to ditch the complexity of React and other SPA frameworks in favor of server side rendering. I am able to express the HTML in Kotlin using Kotlinx.html and I am using Tailwind to manage the css and daisy.ui for a ui component library.

A web app in 2025 with No JavaScript??

Yes – well, a little bit of JavaScript, but that is abstracted away inside of htmx, which powers the partial-page reloads necessary to make the web application fully interactive.

Spring Boot

Admittedly I chose Spring Boot mostly to reduce the amount of new tools and frameworks I had to learn and to get going quickly. I played around with Ktor but ended up sticking with Spring since it’s battle tested and widely used in the JVM community.

Advantages

Single deployable application

• The entire application, both backend and frontend, can be deployed at once.

• The database schema is managed in flyway which automatically updates with each deployment

Performance

• Server side rendering and htmx reduces many of the back and forth http calls between the client & server and make the application feel fast

• Null safety & immutable data flow keeps the application stable and prevents most crashes

Designed for Full Stack Engineering

• This setup makes it easy for engineers to build and test their changes across the entire stack.

Challenges so far

ORM

I tried out nearly a dozen different Object Relational Mappers but they had one or both critical flaws:

• They did not allow hydrating the object from the constructor, which is required for null-safe Kotlin data classes.

• They did not allow us to directly use SQL to create queries in the repositories.

I ended up writing my own ORM leaning on my experience at Meta using reflection and the Kotlin compiler apis.

Hot reload

The biggest drawback of using Spring Boot is that it’s slow to boot up, which makes rapid UI development a bit cumbersome. I am looking into hotswapagent but I haven’t gotten to it yet.

Thymeleaf

Before I discovered kotlinx.html I was using thymeleaf for the front end templating engine. It is horrible: the syntax is awkward & difficult to debug and it relies on a lot of magic to get the data model into the template. I will be re-writing all these views anyway as the product evolves but I can’t move away from this garbage fast enough.

ModelMapping

ModelMapper doesn’t work with Kotlin constructors so I had to use MapStruct which requires a small amount of boiler plate for each object. I am considering writing my own Kotlin centric ModelMapper using the same approach as the custom ORM at some point. I want to be able to support lazy loading of type objects as well.

What’s next?

We are hiring for the following roles:

• Full Stack Founding Engineer

• iOS Engineer

If you’re interested in hearing more about these positions or have any feedback on the tech stack reach out to Joe

joe@seg.tax