Heyy
Hey indiehackers community! 👋 I’m Yigithan, founder of GetsFlow. We are bootstrapping this platform from Ankara, Turkey (the defense and deep-tech hub of the country) with zero seed funding or marketing millions. Traditional ERPs and MES systems for heavy industries are rigid, slow, and incredibly painful to customize. We built GetsFlow as an AI Business Operating System that generates production-ready UI and custom database layers live on the browser, tailored to each factory's exact operational needs. The system is already proven, live, and running in production for a high-security defense industry client. Here is what's under the hood of our core engine, Tessera AI: 1. 2-Step Human-in-the-Loop Discovery: Instead of writing code blindly from weak text prompts, Tessera asks max 4 questions, generates a plain text plan for 1st consent, designs visual mockups for 2nd consent, and only then codes. 2. Strict TSX Codegen Sandbox: We route difficult tasks to top-tier models to write single-page TSX code. Our browser-side validator blocks fetch, eval, require, and dynamic imports. It only executes from a strictly whitelisted UI and local data layer (@/lib/tessera-data). 3. Self-Healing Compilations: If browser-side compilation fails, our TesseraErrorBoundary catches it, logs the exact console/diff error back to the model, and attempts a fix. If the drift persists, it halts compilation to protect token budgets. 4. Tenant-Isolated Data Layers: Tables are provisioned with automated PostgreSQL Row-Level Security (RLS) bound to tenant IDs. We’re here today to show that robust, secure, otonom AI engineering can run safely in high-stakes enterprise environments. I’d love to hear your thoughts on our browser-side sandbox model and how you deal with LLM code-generation drift in your own apps. Ask me anything! 🚀
The human-in-the-loop approach is really interesting, especially the decision to validate the plan and visual mockup before generating the code. i'm curious as you move from building the platorm to having more customers using it , what parts of the buisness do you expect to become the most repetitive or time consuming outside of the actual product development?
Interestingly, the biggest time sink today isn't Tessera itself — it's training customers on our ready-made industry panels. We currently offer pre-built panels for CNC machining, furniture manufacturing, and textile production. They're designed to be simpler than many alternatives on the market, but we still get recurring requests for additional training after the initial onboarding.
The initial training is included in the contract, while additional training sessions are billed at €500 + applicable taxes. As we scale, we expect this to become one of the areas we'd most like to automate through better onboarding, documentation, and in-product guidance.
That makes a lot of sense. The fact that additional training is already something customers are willing to pay €500+ for makes it especially interesting as a scaling bottleneck.
I'm curious about the repeat requests are they usually the same questions/topics coming up across customers, or does each customer tend to need something quite different? That seems like it would determine whether better documentation/onboarding could actually reduce the training load.
It’s a mix of both, but there’s definitely a recurring pattern.
A large part of the additional training is around the same core topics — understanding how the panels are structured, setting up workflows correctly, and getting the most out of the features they already have access to. Those are the areas where better documentation and in-product guidance could probably eliminate a significant amount of repetitive training.
The more challenging part is that each customer also brings their own production processes and terminology. Even when two companies are in the same industry, the way they organize their operations can be quite different, so there’s still a need for some customer-specific guidance.
Our goal isn't necessarily to eliminate training completely, but to make the initial product learning as self-serve as possible and reserve the €500+ sessions for genuinely customer-specific workflows and advanced use cases. I think that would make the model much more scalable.
That distinction is really interesting. It sounds like the opportunity isn't to remove the human element, but to move the repetitive 80% into a self-serve layer and keep the higher-value customer-specific work for the paid sessions.
Out of curiosity, who's currently responsible for turning those recurring training questions into documentation, onboarding material, or in-product guidance? Is that something you and the team handle yourselves as they come up, or do you already have a process for capturing and systematizing them?
It’s actually a bit different for us because GetsFlow isn’t just a product we sell to customers — we actively use it ourselves.
We originally built and configured our own GetsFlow environment around our internal needs, so we’re constantly using the same system we provide to customers. That gives us a very direct feedback loop.
In the background, our own GetsFlow environment collects and structures the data coming from our workflows, while Tessera actively analyzes it and provides suggestions for improvements, adjustments, and areas that may need attention.
So rather than having a separate process where we manually collect recurring questions and then turn them into documentation, we’re using the product itself as part of that learning loop. When we identify a recurring issue or pattern internally, it can feed back into how we structure the product, onboarding, and guidance for customers.
In a way, we’re using GetsFlow as its own testing ground before and while we scale it to other companies. That’s also why the product is quite closely aligned with real operational needs rather than being designed purely from a theoretical SaaS perspective.
That actually makes a lot of sense. Using GetsFlow internally as a testing ground probably gives you a much more realistic feedback loop than trying to predict what customers will need.
Out of curiosity, with all the internal workflows, data structuring, and feedback loops you're running, are there any recurring tasks around the system that still end up being manually handled by you or the team?
I'm asking because I’m building TaskRelay around taking those kinds of recurring operational tasks off founders’ plates.
That’s actually one of the core ideas behind GetsFlow. We still have manual work from time to time, but the system is designed to identify recurring operational issues and address them at their root cause.
Similar to how Tessera analyzes problems during development, our GetsFlow environment continuously looks at workflows, recurring actions, data patterns, and bottlenecks. When it detects a recurring issue, it performs a kind of root-cause analysis and suggests or applies an improvement to the workflow.
The important part is that we’re not just automating the same task over and over. The system tries to understand why the issue keeps occurring, solve the underlying problem, and prevent us from having to deal with the same issue again.
That gives us a similar continuous improvement loop on the operational side that Tessera provides during development.
That makes sense. So the goal isn't really to automate the task itself, but to figure out why the task keeps happening and remove the underlying bottleneck.
That actually makes me curious when GetsFlow identifies an issue that requires something outside the system's capabilities, what usually happens next? Is that something you or the team handle manually, or do you have a process for getting those things done?
When the system encounters something it can’t solve on its own, our engineers step in and perform a root-cause analysis. The goal isn’t just to manually solve that particular case, but to teach the system how to handle that type of problem in the future.
Once we understand the underlying issue and determine the right solution, we feed that knowledge back into the system so it can recognize and handle similar situations itself going forward.
We have a very powerful AI engine behind the system, so we see these cases as opportunities to expand what the system is capable of rather than as permanent manual tasks.
Over time, that means the boundary of what GetsFlow can handle keeps expanding as the system learns from the problems our engineers encounter.
What caught my attention is the gap between “customized to each factory” and “operating system.” Those describe two very different kinds of value: one is about fitting the individual environment, while the other implies something that holds across environments. The fact that you already have a high-security production deployment makes that tension particularly interesting.
That’s a great observation. The “customized to each factory” part describes the output, while “operating system” describes the layer we’re building underneath. Tessera generates the workflows, UI, and business logic around how each company actually operates, rather than simply configuring a fixed ERP.
The way we keep this scalable and secure is through a shared platform architecture with strict tenant isolation and tenant-based Row Level Security (RLS). Each deployment can be highly specific to a customer while the underlying infrastructure, security model, and core engine remain consistent.
That tension is actually one of the most interesting engineering challenges for us: making the generated system deeply specific to each environment without turning every deployment into a completely separate product.
That’s helpful context. The tension between deep customer-specific systems and a repeatable underlying platform is an interesting one.
I’d like to continue the conversation outside the thread. What’s the best email to reach you on?
Absolutely! You can reach me at "info at erkindustry dot com" I’d be happy to continue the conversation and dive deeper into the architecture.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.