A mini ERP with coda?

Hi all,

I was thinking of building a mini ERP for a production company. It can be a single doc, but more likely a cross-doc

They’re a small company <10 employees and I think it’s too early for them to get a full-on production system (that cost >50k to just start using).

The functionality would be:

Raw Materials warehousing & inventory
Semi-finished product warehousing & inventory
Finished product warehousing & inventory
Tracking the measurements of semi-finished products over time
Tracking the batches of production
Finally tracking the usage of inventory over time

This is more or less a snapshot and I’m just wondering in the community maybe someone has created similar things and knows what the best approach would be?

Is it better using cross-doc or more or less a single doc for everything?
Also, will I run into any speed issues if I’ll have ±100 new row entries per day?
Or maybe I shouldn’t even try to use Coda and just use a different software?


Dear @Rokas_Jurkenas,

To call it an ERP system is to my opinion a little too much from the good, but there are options to build a tailored system that could benefit the company and it’s employees.

I have some experience with building modules that improve business processes, but several things you will need to find out:

  • What is the current system the company manages their resources. I have examples where small companies, but been growing didn’t have ANY system in place. Just the fact that their business is growing, the owner identified that something needed to happen to keep track. It was not possible anymore just to remember.

If the owner doesn’t agree on this no way to take own initiative, because he/she will not allow

  • When you get the “green light”, I recommend to go step by step and start with the “raw materials” warehouse. When the owner gets back the feeling of having control over this aspect of the business the next step will be more easy.

  • Check out the know how on computers of the staff that will work with your created tool, including English. (Although most of the system you will be able to build in the local language, still certain areas remain in English)

  • Try to map out all the details you need to gather, just to get the right feeling on the amount of info you need to get in the system.

  • How dynamic is the stock flow. Pieces in/out - day. Is it necessary to have a history of the stock or not? Is all stock of the same type or are the difference big. For example an apparel producer has in stock fabrics and accessories like buttons and zippers. Both have their specifics in how to be managed.

  • Have you concerned the fact that in production “time management” is important, to synchronize all the processes to be at the right place on the right time, to avoid bottle necks and or cash-flow issues. Personally in many cases I spend a rather big amount of my time to train the staff and get them trust that it’s not gonna take their job, but they will be able to focus on more important things that add value to the company.

  • I should not focus to much to connect the modules, although that would be ideal, it’s not realistic at this stage. You could only implement some “cross doc”, functionality for certain smaller info, that you want to hide, like privacy concerned matters.

Instead of continuing to go in more details, that you know better on the business you have in mind, I recommend to think about what can I do with 20% of the resources to solve/improve 80% of the problems I have at this moment.


Hi @Rokas_Jurkenas I have spent the last two years building out an ERP for a production company on Coda. You will most likely need to split each of the major functions you want to accomplish into several docs so that they remain snappy enough that the users will enjoy using them.

My architecture is to have one single source of truth (SSOT) doc with all of the main Tables, and then create satelite docs to perform the various ERP functions, each draw and syncronizing the information from the Tables doc.

The biggest limitation right now is that you will be working in the satelites and need to cross-doc the information back to Tables, and while this works, it isn’t real time and detracts somewhat from the user experience.

Even with this broken up architecture, you will probably run into performance issues if you are adding 100 rows per day. There are ways to mitigate this with archiving information via cross doc AND Coda is continually making performance improvements, but its something to consider.


Thank you for the comments, I’ll look into them. I’m currently aware of the requirements, just mainly wondering is Coda capable of handling such a system.

I was thinking of doing cross-doc for the sensitive information, however one issue I have is if I have all my information in one doc, the speed could be very poor.

As for the first steps “Raw materials” warehouse definitely sounds like a good place to start, thanks!

1 Like

Thanks for sharing your insights @Johg_Ananda!

Does that mean that you write all the relevant formulas, analytics (graphs) in your satellite docs and just keep the main doc as a database?

Any ideas what the minimum delay is?


RIght now you can set the sync to be manual, hourly or daily; so the user can force a sync, and that takes a few minutes. However sometimes its not easy to make it obvious that a sync needs to be manually forced. In my use case, perhaps you can make it more clear … and I think Coda is very aware of the issue and will eventually get it to work seamlessly.

An hour works pretty well for most workflows, its just something to be aware of and you need to design your schema around it.

1 Like