From a sourcing workflow to a real product
Gillnet did not start as a SaaS product.
It started with an operational problem.
Solvism founder Jonathan Garcia had years of recruitment knowledge, established sourcing methods, candidate evaluation logic and outreach practices. The question was how to turn that expertise into a system that could remove repetitive sourcing work without removing the judgment that makes recruitment work.
The initial need was straightforward:
Take a vacancy, understand it, search for relevant candidates, evaluate them, prepare personalized outreach and let the recruiter stay in control of the important decisions.
But turning that into software required much more than connecting an LLM to a search API.
The system had to manage long-running workflows, candidate state, scoring, human approvals, outreach generation, Slack interactions, external providers and eventually multiple users and workspaces.
DitchNow owned that technical evolution from the first workflow prototype through Gillnet v2.0.
The operational problem
Recruitment sourcing contains a lot of repetitive work around a relatively small number of high-value human decisions.
For every vacancy, recruiters repeatedly need to:
- interpret the role and its non-negotiable requirements;
- translate those requirements into sourcing criteria;
- search across candidate sources;
- review incomplete or inconsistent profiles;
- compare candidate experience against the vacancy;
- decide who deserves further attention;
- prepare personalized outreach;
- review that outreach;
- send it through the correct recruiter account;
- keep track of the state of every campaign.
Automating all of that blindly would have created a different problem.
Gillnet therefore had to automate the mechanical work while keeping recruiters explicitly involved in candidate and outreach decisions.
The result needed to be an AI-assisted sourcing system, not an autonomous recruiter.
Phase 1 - Gillnet Lite: prove the workflow first
We deliberately did not begin by building a large SaaS platform.
The first version was built from the ground up as a set of n8n workflows, with Slack as the entire user interface.
The objective was to prove the operational flow before investing heavily in application architecture.
The workflow connected the main sourcing stages:
Vacancy intake → vacancy interpretation → candidate search → enrichment → scoring → review → InMail generation → approval → outreach
Slack gave the recruiter a familiar environment for operating the system.
This version gave us something much more valuable than an architecture diagram:
a working workflow that could be tested against actual recruitment behavior.
It also exposed where an automation-first architecture would eventually become limiting.
As campaigns became more stateful, search became more iterative and review workflows became richer, it became clear that continuing to expand everything inside n8n would create unnecessary fragility.
That was the point where the architecture needed to evolve.
Phase 2 - Gillnet v1.0: rebuilding the workflow as an application
The second stage was not about adding another automation.
It was about converting the validated workflow into a real software product.
We moved away from the n8n-first architecture and rebuilt the system around a structured application backend.
Gillnet Lite became Gillnet v1.0.
The new architecture introduced persistent application state and separated the individual stages of the sourcing workflow into controlled backend processes.
Instead of Slack messages being the workflow itself, Slack became a user interface in the workflow.
.png)
That distinction mattered.
Gillnet could now maintain campaigns independently from individual Slack interactions and coordinate:
- structured vacancy parsing;
- candidate discovery;
- profile enrichment;
- scoring;
- campaign state;
- candidate review;
- InMail generation;
- message approval;
- provider-backed outreach;
- workflow retries and asynchronous processing.
The system also gained a much stronger human-in-the-loop model.
Recruiters could inspect candidate reasoning rather than simply receiving a score.
Candidate reviews exposed signals such as:
- title fit;
- skills fit;
- seniority;
- location;
- supporting reasoning;
- identified risks.
Recruiters could then approve, hold or reject candidates before Gillnet moved forward.
The same principle applied to outreach.
Generating an InMail did not mean sending an InMail.
The recruiter remained the decision-maker.
Slack became a product surface
Slack remained central to Gillnet because the objective was not to force recruiters into another tool unnecessarily.
Gillnet v1.0 therefore evolved into a proper Slack workspace application.
.png)
The Slack experience supported operational actions such as:
- creating a new vacancy;
- checking campaign status;
- reviewing candidates;
- requesting additional candidates;
- generating InMails;
- reviewing outreach;
- approving messages for delivery;
- following campaign progress through threaded updates
.png)
The product could keep recruiters informed while longer-running sourcing jobs continued in the background.
This was a significant change from the first version.
The first Gillnet Lite workflow lived largely inside Slack.
Gillnet had a backend of its own, while Slack became one interface into it.
Compliance and human oversight
As Gillnet moved from workflow automation into a real recruitment application, compliance became part of the product architecture rather than a separate legal checklist.
Because the system processes candidate data and uses AI to support sourcing decisions, Gillnet v1.0 was designed around meaningful human oversight. Recruiters remained responsible for candidate decisions and outreach. The AI could score, explain, recommend and prepare messages, but it could not independently progress sensitive recruitment actions without human review.
The product also introduced GDPR-supporting controls and auditability directly into the workflow, including:
- candidate retention and deletion handling;
- suppression and do-not-contact logic;
- persistent records of candidate review decisions;
- traceability of approvals, rejections and outreach actions;
- clear separation between AI recommendations and human decisions;
- review checkpoints before candidate progression or message delivery;
- audit-style records showing who approved what and when.
This created a stronger foundation for GDPR and EU AI Act readiness as Gillnet evolved into a production product. Rather than treating compliance as something to add later, the architecture was designed so that privacy controls, decision traceability and human-in-the-loop review were part of the operational workflow itself.
Phase 3 - Gillnet v2.0: productization and scalable infrastructure
Once the backend workflow was established, the next problem became product scale.
A system designed around one workspace and one interaction surface is very different from one intended to support multiple customers.
Gillnet v2.0 therefore focused on the infrastructure and product layers required to move beyond the original internal-tool architecture.
Multi-tenancy
We introduced a multi-tenant architecture so campaigns, users, workspace context and application state could be separated correctly.
This required more than adding a tenant_id column.
Tenant context had to flow through:
- authentication;
- campaign creation;
- Slack events;
- workflow execution;
- data access;
- review queues;
- integrations;
- UI state.
The architecture had to know not only what action was taking place, but for whom.
Slack OAuth and multi-workspace installation
The original Slack integration could assume a predefined workspace.
That assumption had to disappear if Gillnet was going to become a product.
Gillnet v2.0 added Slack OAuth, allowing the application to be installed into multiple Slack workspaces.
The application therefore needed to manage workspace-specific:
- installation state;
- OAuth credentials;
- users;
- routing;
- event context;
- tenant association.
This changed Slack from an internal integration into a distribution surface for the product.
A Web UI alongside Slack
Slack works extremely well for notifications, decisions and workflow interaction.
It is less suitable for every kind of operational overview.
Gillnet v2.0 therefore introduced a Web UI alongside the Slack application.
.png)
The Web UI provided another surface for interacting with the same underlying system.
It supported areas such as:
- campaign overview;
- pipeline visibility;
- review queues;
- campaign status;
- candidate information;
- workflow actions;
- operational navigation.
The important architectural decision was that Slack and the Web application were not two separate products.
They were two interfaces into the same backend state.
A campaign created or reviewed through one surface needed to remain consistent when viewed through the other.
That meant solving synchronization and identity questions across:
Web user ↔ tenant ↔ Slack workspace ↔ campaign ↔ workflow
rather than simply building another frontend.
Embedded AI assistance
Gillnet v2.0 also introduced an AI assistant into the Web application.
The objective was not to bolt a chatbot onto the product because AI assistants were fashionable.
The assistant was designed as another interface into Gillnet's operational context.
That creates a path toward users being able to interact with the sourcing system conversationally while the underlying application still maintains deterministic state and workflow controls.
.png)
The important architectural principle remained the same throughout the project:
the AI can assist with reasoning; the application owns the workflow.
What DitchNow owned
Across the project, DitchNow's responsibility went substantially beyond implementation of individual tickets.
We owned the technical progression of the product.
That included:
Product architecture
Choosing when a lightweight workflow architecture was sufficient and when it had reached its limits.
Workflow architecture
Breaking the sourcing process into controlled stages with persistent state and human review points.
AI integration
Applying AI to vacancy interpretation, candidate evaluation, reasoning and outreach generation without allowing the LLM to become the application state machine.
Backend engineering
Moving the product from n8n workflows into a structured backend capable of running asynchronous sourcing workflows.
Slack application development
Turning Slack from a collection of workflow messages into a proper workspace application.
Multi-tenant architecture
Preparing Gillnet to operate across customers and workspace contexts.
Slack OAuth
Moving from a fixed Slack integration to installable multi-workspace infrastructure.
Web application
Building a dedicated product surface alongside Slack.
Cross-surface integration
Keeping campaign and workflow state coherent between Slack and Web.
AI assistant
Adding conversational product interaction on top of the application architecture.
Production infrastructure
Handling the operational infrastructure required to deploy and run the product rather than stopping at a local prototype.
The architecture changed because the product changed
One of the most important parts of this project was knowing when not to keep the existing architecture.
n8n was useful at the beginning.
It allowed us to validate the sourcing workflow rapidly without spending the first weeks building infrastructure for assumptions that had not yet been tested.
But once the workflow became a product, the trade-offs changed.
Persistent state, retries, review history, multi-user behavior, application APIs, tenancy and multiple user surfaces all become much easier to reason about when they are explicit application concepts.
So we did not spend months trying to turn n8n into something it was not designed to be.
We kept the validated operational logic and changed the architecture around it.
The progression was:
Sourcerer
n8n workflows + Slack-only UI
↓
Gillnet v1.0
Application backend + persistent workflow state + Slack workspace application
↓
Gillnet v2.0
Multi-tenant application + Slack OAUTH + multi-workspace installation + Web UI + AI assistant
That progression is a good example of how DitchNow approaches early-stage technical products.
The correct architecture for validating a business process does not have to be the architecture that takes the product to scale. The more users approve and want, the more the products get build.
Production complexity is usually outside the AI strap-on
The AI portions of Gillnet matter architecturally as they are part of larger pipeline and product workflows. But the engineering complexity sits around them.
A production sourcing product has to deal with questions such as:
- What happens when search does not return enough candidates?
- How does a campaign continue asynchronously?
- What does the recruiter see while the system is working?
- How are candidate decisions stored?
- Can a recruiter request another search cycle?
- Which workspace owns the campaign?
- Which user initiated it?
- Which recruiter account should send the outreach?
- What happens when a provider fails?
- How does Slack know which campaign an interaction belongs to?
- How does the Web UI see the same state?
- How does another customer install the Slack application?
- How are human approvals preserved before outreach?
These are not prompt-engineering problems.
They are product-engineering problems.
And solving them is what turns an AI workflow into software that people can actually use.
Where Gillnet is today
By September 2026, Gillnet had moved significantly beyond the original Gillnet Lite n8n workflow.
The product had:
- a real application backend;
- Slack-based sourcing and review workflows;
- persistent campaign state;
- candidate scoring and review;
- outreach generation and approval;
- a Web UI;
- multi-tenancy;
- Slack OAuth;
- multi-workspace installation architecture;
- connected Slack and Web surfaces;
- an embedded AI assistant;
- production-oriented infrastructure.
Gillnet is also being used in a customer context.
Solvism is now positioning Gillnet publicly as its sourcing product, and Gillnet is one of the primary sponsors of Sourcing Summit Europe 2026 in Amsterdam. Check out about this more here.
What this project proves about DitchNow
Gillnet represents exactly the kind of technical ownership DitchNow was created to provide.
Clients do not always arrive with a perfect product specification.
They often arrive with:
- domain expertise;
- an operational problem;
- a working manual process;
- some experiments;
- and a belief that software or AI could make it better.
The job is not simply to code what is written down.
The job is to understand what stage the product is actually in and choose the right level of engineering for that stage.
With Gillnet, that meant starting lightweight.
Then replacing the lightweight architecture when the product demanded more.
Then building the infrastructure needed for the next stage.
DitchNow can own that entire path - from workflow architecture, through application architecture, to production.
That is the point of the Silent CTO model.
You bring the market knowledge and the problem as the Solo Founder or Startup or a team in larger company.
We take responsibility for turning it into a working technical system.
Need to turn an operational workflow into a real product?
If you have an AI-heavy workflow, internal tool or early prototype that needs to become reliable software, DitchNow can own the technical path from architecture through production.