davidpolberger

I'm working on turning our statically-typed formula engine -- that we use for Calcapp, our app builder -- into a real hosted solution (as well as a library). I discussed it in July last year (https://news.ycombinator.com/item?id=44702833#44704642) and have been working full-time on the project since the beginning of the year.

I figured "I already have a battle-tested solution, I just need to make it modern and spiffy, build a website for it and see if there's any interest -- in the age of Claude Code, this should be fast work!"

Wrong. Taking an internal library and offering it to others -- complete with documentation and modern tooling -- is an immense project, even with the help of AI agents.

Is there a market for a "formula engine in a box"? I don't know. But I also didn't know whether there would be a market for Calcapp either, and that has supported me working full-time for the past seven years. So I'm willing to take another chance.

I'm a co-founder of Calcapp, an app builder for formula-driven apps, and I recently received an email from a customer ending their subscription. They said they appreciated being able to kick the tires with Calcapp, but had now fully moved to an AI-based platform. So we're seeing this reality play out in real time.

The next generation of Calcapp probably won't ship with a built-in LLM agent. Instead, it will expose all functionality via MCP (or whatever protocol replaces it in a few years). My bet is that users will bring their own agents -- agents that already have visibility into all their services and apps.

I hope Calcapp has a bright future. At the same time, we're hedging by turning its formula engine into a developer-focused library and SaaS. I'm now working full-time on this new product and will do a Show HN once we're further along. It's been refreshing to work on something different after many years on an end-user-focused product.

I do think there will still be a place for no-code and low-code tools. As others have noted, guardrails aren't necessarily a bad thing -- they can constrain LLMs in useful ways. I also suspect many "citizen developers" won't be comfortable with LLMs generating code they don't understand. With no-code and low-code, you can usually see and reason about everything the system is doing, and tweak it yourself. At least for now, that's a real advantage.

This is wild. I gave it some legacy XML describing a formula-driven calculator app, and it produced a working web app in under a minute:

https://aistudio.google.com/app/prompts?state=%7B%22ids%22:%...

I spent years building a compiler that takes our custom XML format and generates an app for Android or Java Swing. Gemini pulled off the same feat in under a minute, with no explanation of the format. The XML is fairly self-explanatory, but still.

I tried doing the same with Lovable, but the resulting app wouldn't work properly, and I burned through my credits fast while trying to nudge it into a usable state. This was on another level.

I like to use Claude Code to write deterministic computer programs for me, which then perform the actual work. It saves a lot of time.

I had a big backlog of "nice to have scripts" I wanted to write for years, but couldn't find the time and energy for. A couple of months after I started using Claude Code, most of them exist.

I'm a co-founder of Calcapp, an app builder for formula-driven apps using Excel-like formulas. I spent a couple of days using Claude Code to build 20 new templates for us, and I was blown away. It was able to one-shot most apps, generating competent, intricate apps from having looked at a sample JSON file I put together. I briefly told it about extensions we had made to Excel functions (including lambdas for FILTER, named sort type enums for XMATCH, etc), and it picked those up immediately.

At one point, it generated a verbose formula and mentioned, off-handedly, that it would have been prettier had Calcapp supported LET. "It does!", I replied, "and as an extension, you can use := instead of , to separate names and values!") and it promptly rewrote it using our extended syntax, producing a sleek formula.

These templates were for various verticals, like real estate, financial planning and retail, and I would have been hard-pressed to produce them without Claude's domain knowledge. And I did it in a weekend! Well, "we" did it in a weekend.

So this development doesn't really surprise me. I'm sure that Claude will be right at home in Excel, and I have already thought about how great it would be if Claude Code found a permanent home in our app designer. I'm concerned about the cost, though, so I'm holding off for now. But it does seem unfair that I get to use Claude to write apps with Calcapp, while our customers don't get that privilege.

(I wrote more about integrating Claude Code here: https://news.ycombinator.com/item?id=45662229)

I've been using Claude Code a lot lately, and I've been thinking of integrating it into our SaaS tool (a formula-driven app designer). I've been holding off primarily because I've been afraid of the cost (we're not making much money off our $9/mo. customers as it is, and this definitely wouldn't help that).

However, it's becoming clear to me that individual apps and websites won't have their own integrated chatbots for long. They'll be siloed, meaning that they can't talk to one another -- and they sure can't access my file system. So we'll have a chatbot first as part of the web browser, and ultimately as part of the operating system, able to access all your stuff and knowing everything about you. (Scary!)

So the future is to make your software scriptable -- not necessarily for human-written scripts, but for LLM integration (using MCP?). Maybe OLE from the nineties was prescient?

Short-term, though, integrating an LLM would probably be good for business, but given that I'm our only engineer and the fact that our bespoke chatbot would likely become obsolete within two years, I don't think it would be worth the investment.

Other apt comparisons to what I'm building include HyperFormula and Microsoft Power Fx.

No, not really. GoRules appears to be a decision engine that allows non-technical users to define rules visually through a graphical interface. Engineers can then interpret and evaluate these rules using provided libraries.

What I'm building is a formula engine that validates, compiles, and evaluates Excel-like formulas. Compared to GoRules, it’s more akin to the ZEN expression language component than to the broader GoRules system.

I'm working on an engine for Excel-like formulas, which will be available both as a library and as a service (which I've mentioned on HN a few times before). I originally started work on the engine back in 2008, when our app builder needed it.

This is a wheel I see people reinventing all the time, often for use in SaaS applications. The implementations are often underwhelming: function support is limited, documentation is sparse to non-existent and errors are typically only communicated at runtime -- if at all. Formula editors usually lack autocomplete, making them frustrating to use.

I've spent years solving all these problems (with a statically-typed language), and I'd love for others to benefit from the work. I have extracted the formula engine from our app compiler, so the library is nearly complete. The runtime part (evaluating formulas) has been rewritten in TypeScript. Next, I'll build a service around it to validate, compile and evaluate formulas -- which should be fun.

I'm planning to do a Show HN once I have a preview up and running.

Thanks, I'll point their support staff to that document.

I was told that Firefox is no longer supported by a support technician over the phone. A different support technician wrote this to me in an email:

"Regarding the printing option on Firefox, I'm afraid this is no longer within Stripe's support scope."

(I complained that it is not possible to print certain pages of the Dashboard through Firefox, while Chrome works acceptably well.)

I know this doesn't add much value to the discussion, but I was really proud of my UIN when I was a teenager. And this may be my last chance to flaunt it, so here it is:

1779900

So back in the day, these were known as Universal Internet Numbers, or UINs. You have to admire the sheer audacity of using that name for the user identifiers of a service you're building. I believe they were renamed to "ICQ#" later.

Thanks, it certainly has been. After only a couple of years in the software industry proper, though, I felt I had seen all I needed to see. Crunch time. Arbitrary, ill-informed management decisions. Management who didn't believe in the product the team was passionate about. Products canceled through no fault of anyone working on it. Office politics and bickering.

With my own business, I gain agency. If the product fails, it's because I failed to market it properly, or the product vision was bad and did not resonate with enough customers, or because I failed to execute on that vision. When all the decisions are out of your hands, and you can't even see what prompted them, they can feel capricious and arbitrary.

With my own business, I am in control. I don't have one boss, I have hundreds of them. And as long as I continue to provide them with value, I get to continue doing what I'm doing. I like those terms.

I have been self-employed since 2008, when I quit my job in software engineering to go all-in on my software business (that dated from 2003). That failed spectacularly, because I only focused on technology and not on the value I was creating, and with few customers, I had to do on-site contracting for more than a year before going on full-time parental leave.

I then rebooted my software project, launched a landing site and started talking to prospects (hundreds of them), before I set out to pivot my existing product to something that might gain traction. (I wound up throwing away 95 percent of the code.) I spent 2014 through 2019 with the product in beta, barely making a living off of a few enterprise support contracts and doing freelance photography (and depleting my savings), but spending at least 80 percent of my time on building the product and getting it to a finished state.

(Some people seem to be able to build a product in a weekend that gets eager customers. I'm not one of those people, choosing to build something that was, in retrospect, much too big of a project for one person. I probably also spent too much time polishing the product before commercializing it, likely due to a fear of failure.)

In 2019, the product was finally commercialized as a SaaS service. I remember thinking that I either wanted it to be a spectacular success, or a spectacular failure (so that I could focus on other things, after close to 20 years).

It was neither, but has been growing steadily ever since. I would have made much more money working for someone else, but the freedom is unparalleled. I get to set my own hours and focus on things I consider important. I enjoy doing everything from support calls and UX work to building a compiler and a type system (that I have mentioned before on HN).

I also have no one I need to answer to, other than our customers. That has been important over the past couple of years, when a series of health emergencies in my family has diverted my attention elsewhere. I have been very fortunate to be able to do so, focusing on what's important, without having to ask permission to cut down on work temporarily.

Overall, I wouldn't trade this for anything. This year, my product will gain a sister product in a more lucrative field (I'm hoping), and I have plans to commercialize my compiler, both as a service and as a traditionally-licensed library. So I'm excited to stay solo and keep working on building the business.

Could someone provide insights into the implications of a hypothetical Schrems III for EU-based SaaS companies that host their servers in the US, particularly those containing Personally Identifiable Information (PII) like email addresses? Essentially, would Schrems III mean that we'd need to immediately move our servers to EU soil, or risk fines?

Everyone -- thanks for your constructive comments. I think that we'll start off by releasing the libraries under permissive licenses, and see how that goes. Releasing the code of the user-facing products publicly would probably provide little value for others (as the code would not be open source), and there are indeed risks.

No, it just feels like the right thing to do, and I'm hoping that others could benefit from the work. While I would like to release some libraries under permissive licenses, I really have no plans to shepherd collaborative open source projects (which I think might turn into a huge time sink). Others would obviously be welcome to fork and maintain these projects, but I would prefer for them to simply be read-only versions of what we're using in production.

A would-be competitor, in a country not respecting intellectual property laws, might get a few customers by launching our product and charging only a fraction of what we charge. However, what will this competitor do when their customers request new features or report bugs? Obviously, we'd be a lot more nimble in responding to such requests, so maybe this shouldn't be such a big concern after all.

Also, if this does becomes a problem, we can just stop releasing new versions publicly, at which point the competitor's offering would stagnate, while our offering would continue to improve.

Good point.

The service is named Calcapp, an app builder for spreadsheet-savvy users (https://www.calcapp.net). The codebase weights in at half a million lines of code and documentation, with lots of generic utility libraries I have written over the past ~20 years, in Java and JavaScript.

I don't think that releasing the user-facing app creator and runtime libraries under a permissive license would be smart. However, I would still like that code to be out there, and for the utility libraries to be available for anyone to use under a permissive license.

The one downside I can see myself is that by making the source available, we might reveal security vulnerabilities. Sure, security through obscurity is not a good idea in and of itself, but revealing that we haven't updated a key, vulnerable library might still be problematic.

You're probably referring to the wonderful nXML mode, which has been a part of stock Emacs for years now: https://www.gnu.org/software/emacs/manual/html_mono/nxml-mod...

Does anyone know if this works well (to the extent that it does), because the documented Blender Python API was part of the GPT-4 training set, or because the Blender API is fairly predictable?

I'd love to add this capability to our SaaS product, but I've waited for OpenAI to make GPT-3.5 or GPT-4 available for fine-tuning. (Cramming an entire API into the prompt does not seem feasible, not even with support for 32K tokens.)

Back in 2010, I used plasTeX (http://plastex.github.io/plastex/) to convert my thesis to HTML (http://www.polberger.se/components/). plasTeX is "a Python package to convert LaTeX markup to DOM." If memory serves, plasTeX worked rather well, and still seems to be maintained today.

Thanks!

Thanks. I did lots of other things in parallel during the early years. I left my last consulting gig in 2014, so I have been doing in full-time since then.

Yeah, it takes a lot of perseverance to get a startup going. (Or rather, a lifestyle business in my case -- it's not a rocket ship, but I get to work on interesting things and interact with friendly customers, so it really is a great job.)

My father asked me to create Windows apps for the hospital department where he worked as a doctor (calculating drug dosages and the nutritional needs of preterm infants). I figured that there might be others with a similar need and eventually created a SaaS app builder that is currently my full-time job. It's been almost 20 years since that original request. https://www.calcapp.net/blog/2018/04/09/launching-after-15-y...

Works for me, on Firefox and Chrome on Fedora 36, without ad blocking, and Enhanced Tracking Protection enabled on Firefox.

The archive.ph link does not contain any videos. Refer to https://www.nytimes.com/interactive/2022/10/27/world/asia/hu... to access the original article (unlocked).

Unlocked link (with videos, unlike the archive.ph link): https://www.nytimes.com/interactive/2022/10/27/world/asia/hu...

I bet big on Java/Jakarta EE, and the open source application server WildFly, years ago when the web version of Calcapp was born in 2014. I have been very happy with that decision. JAX-RS is a great way to build annotation-driven REST web services with very little boilerplate. WildFly (the open source version of JBoss EAP, essentially) is actively developed by Red Hat, starts quickly and is easy to work with. And the modern incarnation of Java -- with streams and lambdas -- is a great fit for what we do (building a compiler).

The only decision I have come to regret is using JPA, which is short for Java Persistence API (a specification for an ORM -- an Object-Relational Mapping), and where the most famous implementation is Hibernate. As far as ORMs go, Hibernate is probably fine, but I wish I had considered using something more light-weight and closer to the underlying database. As things stand, JPA mostly gets in the way, and I have had to resort to "native queries" (SQL) for our most performance-sensitive code paths.

I don't regret choosing JPA, as much as I regret choosing an ORM.

Also, as others have alluded to, Java is a stable choice. At the same time I chose Java EE and PostgreSQL, I chose AngularJS for our front end, which has been fully superseded by modern versions of Angular. We'll need to spend lots of time replacing AngularJS with React or Angular (we haven't decided yet), so that decision didn't really pan out.

On the server, though, I couldn't be happier with Java/Jakarta EE and PostgreSQL.

(Sorry about the late reply, I suppose I stopped monitoring the thread after a while.)

If memory serves, XPCOM was fairly derivative of COM, but fully cross-platform. (It had to be, as Netscape's browser and its open source successor ran on Windows, Mac OS and lots of different Unix flavors.) For this reason, I didn't include a full section on it in my thesis, but I do mention it in passing.

XPCOM saw overuse in the codebase, which led to bloat and a years-long effort to cut down on its use[1]. However, when I studied XPCOM, it seemed like an excellent way to bring the core ideas of COM to a cross-platform codebase, with C++ and JavaScript language bindings.

[1] https://wiki.mozilla.org/Gecko:DeCOMtamination