Find the process you repeat
List the operational work you did last week and mark the parts you did twice. Onboarding, invoicing, support triage, and reporting are the usual candidates.
Choose one that happens at least weekly. A monthly process is harder to learn from, because you get fewer chances to see it fail.
Write the process before the tool
Write the steps as if you were handing them to a new hire: the trigger, the inputs, the decision, and the output. If a step needs your judgment, say so rather than hiding it in a tool.
The written process is useful even if you never build anything. Most founders discover that two steps were never necessary.
Build the smallest version
Build the one action the process needs: create a record, send a reminder, produce a summary. Keep it internal and keep it small. You are replacing a manual habit, not a system.
Use it for two weeks before adding anything. The changes that matter will come from the work, not from planning.
Hand it off with the boundary
When the first ops hire arrives, hand over the process, the tool, and the parts that still need a person. The boundary is the most valuable part of the handoff, because it prevents silent mistakes.
Keep the tool editable. The new hire will find a case you never hit, and the fix should not require a project.
What to measure
Measure the hours you stop spending and the errors you stop repeating. Both are more honest than a feature list.
Also measure how quickly a new person can run the process. If it takes a week to teach, the process is not written down well enough.
How to run it on Sigla
Describe the process in one workspace, build the smallest tool, and use it on the real work. When the hire arrives, share the workspace and the written steps. Ask for changes by naming the case that broke.
For the build path, read build an internal tool without coding. If the process starts from spreadsheets, the no-code app builder for analysts is the closer fit.
FAQ
Should I build or buy?
Buy the system of record. Build the small process around it that no vendor will make for you.
What if I am not technical?
Describe the process and the decision. The implementation is something you judge by using it, not by reading the code.
When should I hire instead?
When the process is stable enough to hand over and the volume justifies a person. Hiring into an unwritten process usually produces a second version of it.
Does this create maintenance work?
Less than the manual process if the scope stays small. Keep it to one decision and one output, and the maintenance is a few changes a year.