Rendered at 06:52:23 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
BraamV 8 hours ago [-]
Nice idea - tried it "Show me how frontier ai inference cost developed" - fast, easy to use and nice charting capability, but ai didnt interpret question correctly -- showed 1 line only - some blended cost - should have shown cost dropoff by model in multiple lines, also didnt add new models (cut-off was August 25) - think you need a better model for the first analysis- also need to sharpen how this is different from e.g. Claude -- in claude you can upload a bunch of docs and ask it to do some task - it will plan the workflow and execute. Whats the edge here, persistance? i.e. do same thing next month?
kdautaj 2 hours ago [-]
Thank you – that’s a real bug. Tried your prompt and looks like the dashboard drew only the first column. Thank you again, I’m fixing this as we speak – appreciate you taking the time to try this
Re: better model… yes, eventually I’ll upgrade – some context though on architecture: currently, the platform connects to Fred (800k economic series), Stooq (market prices), Edgar, and QuickBooks (w/ oAuth). In production, the info will be either solely pulled from a connector (i.e. QuickBooks, Xero, SAP, or other ERPs) or it will be uploaded via the Files panel, and it will not make up numbers (from model memory). That said, for this showing, if the prompt requests something the platform is not connected to, I allowed the model to fill in the numbers (from memory)… “This will not happen in production…” I left it "on" for this showing to see how people use the flow (and get feedback) vs. getting a “no data connection” type of response.
In terms of Claude (the app) vs. Ekselio.. there are a couple of things that make Ekselio different… execution runs in the browser (local first), so no server side data infrastructure, no warehouse, no copy of your ledgers etc - in accounting and corporate finance (the targeted vertical) this would be critical, considering the sensitivities around financial data - think financials, customer pricing (SKU level data), PII, etc. The only thing that leaves the browser is the planning request (column names only) – i.e. if you upload GL transaction details in the files panel (or pull it from quickbooks or another ERP via a connector) and then prompt it to build an aging schedule (30 days, 60 days, 90 days outstanding by customer), the schema / column names are sent to the LLM while the execution happens in the browser in your machine (privacy, etc).
The other thing is that you can save it, and next month can re-run it on fresh data with one click, with zero planning tokens(and deterministic in execution). Claude code (vs. Claude, the App) can also run locally with local tools but if the results are read or head it to understand the files, those rows leave the machine. Finally, you can export/build model in excel where the workflow SQL (from the nodes) are converted into M Code so it can run in excel with inputs and outputs with a check at the end (workflow output compared to the excel model output (M Code / Power Query)... this is still WIP, as some outputs show up as static right now) – but general idea is to support the workflow output with an excel output kind of like a certificate for audit purposes (i.e. can hand over the files to auditors).
There is also a desktop version that allows you to upload your excel models and it turns them into workflows (with inputs and outputs tying back to the excel model, full circle - wip at the moment); desktop only for now as it needs some fire power and running it on a server would defeat its purpose in terms of local first – the idea is that fp&a teams and accounting teams have a lot of institutional knowledge sitting in their monthly excel models (i.e. operating variance reports, warranty reserve calculations, inventory costing, etc) so there is a lot to unlock there, and automate with privacy, repeatability (zero tokens) and deterministic outputs in mind.
sshussain270 3 days ago [-]
Just a suggestion, recently OpenBB has shutdown (and open sourced their codebase) and its users are probably looking for alternative solutions who are not self-managing it, worth reaching out to them.
kdautaj 3 days ago [-]
thank you, really good tip - I was not aware they shut down their commercial arm. It's unfortunate for the team, but open sourcing everything was the right move. They built something people really loved. There is definitely some overlap on the Market data side of things, but my focus is on the workflows on company's own data (think FP&A teams, or even accounting teams, running recurring CFO type analysis month over month). That said I will definitely look into this more closely. Thank you again. And apologies for the delayed response - on US time (just waking up :-) )
sshussain270 2 days ago [-]
All the best!
adityamishra241 5 days ago [-]
The local-first approach is interesting, especially for finance workflows. Being able to save a workflow and rerun it later without involving the LLM again is a nice touch. Curious to see how this evolves.
kdautaj 5 days ago [-]
Thank you. In finance, from my personal experience, no one wants to re-build anything. Once someone creates a workflow, they should be able to re-run it next month. For example, if you build a monthly operating variance report from your quick books, next time, you should just click re-run.
hackernud3s 4 days ago [-]
Are you talking about Lovable? I don't see it.
kdautaj 4 days ago [-]
Sorry for the delay, had to put my 15 month old to sleep yes, Lovable - I spelled it “Love-able” on purpose-ish since the architecture is different. Lovable builds you an app; this builds a workflow. The LLM plans the steps once (based on file schema), then the actual math runs as SQL in duck-db wasm in your browser. Next month you simply upload the revised file and hit re-run - same SQL (no add'l tokens needed). The AI can still write bad SQL, but it's all visible on the canvas, so it can be checked and once you save it, then next time it is deterministic. For Finance, the local first (sensitive data), repeatability, and transparency matter quite a bit. I connected Fred (econ data, nearly 800k series), and stocks so folks could try it out without needing to upload their own files (in this case it pulls the info as files, you can see it in the canvas section). Quickbooks is also connected, with other ERPs coming in later as I would need to go thru the hoops to get approvals in place (i.e. from Xero, Sage, etc.). I completely get your point though, in terms of it does not feel the same as Lovable. Maybe that is something that I can think through in more detail. Thank you for the comment. Feel free to let me know of any recommendations. I would really appreciate it.
jon9544hn 5 days ago [-]
I’ll mess with it!!
kdautaj 5 days ago [-]
thank you so much, I really appreciate it
tochihenry28 4 days ago [-]
the local approach makes a lot of sense for tools like this. will try
kdautaj 4 days ago [-]
That was my thought process, especially if it’s used on system of records (i.e. QuickBooks, Xero, Net Suite, Sage, etc.) - that said, on the UI side , unsure if some one should just land on the canvas or if the home page is the way to go , flashier but unsure on usability / will see :) thank you again for taking the time to try it, really appreciate it
SenHeng 4 days ago [-]
Do you have a blog or something documenting your thought process?
I’m building something similar for cash flow prediction and management and would love to know more.
kdautaj 4 days ago [-]
Sorry for the late reply, just walking up here (Est US time). No blog at the moment, but something I should be working on - Happy to email you some thoughts. I've been in finance nearly 20 years now, with the last ten in M&A diligence And I can tell you that cash flow is where lots of deals get made or broken - i.e. 13 week cash flow, net working capital peg, etc. Happy to share what I have seen and what I have been thinking about (repeatable workflows, deterministic, etc). I just checked out your blog and I can take a read thru some of the recent ones - I love the fact that it is in both, English and Japanese. I've also included my contact info in my 'about' section if you would like DM me and we can go from there. thank you again for checking this out - any feedback is welcomed.
Re: better model… yes, eventually I’ll upgrade – some context though on architecture: currently, the platform connects to Fred (800k economic series), Stooq (market prices), Edgar, and QuickBooks (w/ oAuth). In production, the info will be either solely pulled from a connector (i.e. QuickBooks, Xero, SAP, or other ERPs) or it will be uploaded via the Files panel, and it will not make up numbers (from model memory). That said, for this showing, if the prompt requests something the platform is not connected to, I allowed the model to fill in the numbers (from memory)… “This will not happen in production…” I left it "on" for this showing to see how people use the flow (and get feedback) vs. getting a “no data connection” type of response.
In terms of Claude (the app) vs. Ekselio.. there are a couple of things that make Ekselio different… execution runs in the browser (local first), so no server side data infrastructure, no warehouse, no copy of your ledgers etc - in accounting and corporate finance (the targeted vertical) this would be critical, considering the sensitivities around financial data - think financials, customer pricing (SKU level data), PII, etc. The only thing that leaves the browser is the planning request (column names only) – i.e. if you upload GL transaction details in the files panel (or pull it from quickbooks or another ERP via a connector) and then prompt it to build an aging schedule (30 days, 60 days, 90 days outstanding by customer), the schema / column names are sent to the LLM while the execution happens in the browser in your machine (privacy, etc).
The other thing is that you can save it, and next month can re-run it on fresh data with one click, with zero planning tokens(and deterministic in execution). Claude code (vs. Claude, the App) can also run locally with local tools but if the results are read or head it to understand the files, those rows leave the machine. Finally, you can export/build model in excel where the workflow SQL (from the nodes) are converted into M Code so it can run in excel with inputs and outputs with a check at the end (workflow output compared to the excel model output (M Code / Power Query)... this is still WIP, as some outputs show up as static right now) – but general idea is to support the workflow output with an excel output kind of like a certificate for audit purposes (i.e. can hand over the files to auditors).
There is also a desktop version that allows you to upload your excel models and it turns them into workflows (with inputs and outputs tying back to the excel model, full circle - wip at the moment); desktop only for now as it needs some fire power and running it on a server would defeat its purpose in terms of local first – the idea is that fp&a teams and accounting teams have a lot of institutional knowledge sitting in their monthly excel models (i.e. operating variance reports, warranty reserve calculations, inventory costing, etc) so there is a lot to unlock there, and automate with privacy, repeatability (zero tokens) and deterministic outputs in mind.
I’m building something similar for cash flow prediction and management and would love to know more.