Valenys Core
Sales, operations, finance, content and commerce in one Laravel system, with an Astro or Next.js front end.
It starts from a product that already works and is shaped around your processes, rather than forcing your processes into someone else’s model. You own the source code and the data.
Mid-sized companies end up with the CRM in one place, invoicing in another, the website at an agency and the shop on a rented platform. Data does not move between them. Nobody has the whole picture. Every change needs three suppliers to agree on a date.
The classic alternative — a large ERP — costs a year of implementation and still does not fit. The other alternative — a stack of subscriptions — fits for a while, then stops, because you cannot change how any of them thinks.
There is a third option, and it is the one most buyers never get offered: start from a complete product, and shape it.
Valenys Core
Sales, operations, finance and hosting in the same place, so the numbers on the dashboard come from the same records the team works in.
A pipeline from first contact to signed contract. Automatic follow-up cadences, so a touched lead always has a next action scheduled. A full company record with the whole history in one place. Duplicate detection across large prospect bases. Offers with line items, discounts and payment schedules. Contracts whose status updates itself. A client portal, support tickets with service levels, and monthly search position reporting.
Invoices, receipts, payments and balances. Several currencies with rates updated daily. Units of measure, VAT handled as a setting rather than as hard-coded logic, and documents that keep the language they were issued in — so an offer sent in German stays in German when it is reprinted a year later.
A headless content system: one Laravel installation administers several websites, isolated from each other, and the front end is built in Astro or Next.js and served statically. Pages are assembled from 25 block types — hero, banner, slideshow, text, features, steps, timeline, testimonials, team, clients, price tables, galleries, forms — reordered by dragging, previewed live, and saved as reusable global sections or templates. A block can be scheduled to appear and disappear on a date, or A/B tested against another. Translations are stored one row per language, with scheduled publishing, releases, approval flows, edit locking and a recovery bin.
Large enough to deserve its own page: B2B accounts and approval flows, several markets from one catalogue, real warehouse handling, and migration that keeps your addresses.
A monthly content plan that has to be approved before anything is generated. Nothing is produced from an unapproved plan — not manually, not by a scheduled job. Then text and image generation, a quality pass, publication to the site and to social channels, and a monthly report.
Claude, Gemini and GPT are all supported, with a spending cap checked before each call and a log written even when a call fails. A retrieval-augmented chatbot that answers only from indexed content. An assistant in the admin panel, and an MCP server so an external agent can work against the same tools — writing drafts, never publishing.
An audit log. Backups verified by checksum and rehearsed against a separate database on a schedule. Access keys scoped to a domain, IP rules, a maintenance mode, security headers, and webhooks to other systems. Fifty-six scheduled tasks handle the recurring work, out of ninety-three console commands.
CRM
Overdue call-backs first, then what is scheduled, then the leads nobody has touched yet. The follow-up cadence writes that list; nobody keeps it in a spreadsheet.
Still moving
The three entries below come from the same log as the changelog page. If it ever goes quiet for a quarter, you will see that here too — which is the point of showing it.
Recently shipped in the platform
A form filled in on your site becomes a lead immediately — not through an integration that can silently break, and not on the next sync. This is the architectural decision the whole platform is built around.
Isolated from one another, administered together.
Most organisations discover their backups do not restore on the day they need them. Ours are rehearsed on a schedule, against a separate database, with a checksum verified first — and copies are pushed to any S3-compatible object store.
Custom fields and custom block types, without touching shared code — so your model can differ from everyone else’s without becoming a fork nobody can upgrade.
Content
Pages are built from blocks — dragged into order, previewed live, scheduled to appear and disappear, saved as templates. One installation administers several sites, and translations are one row per language: a page can be live in English and still a draft in German, and the list is where you see which.
Fair, and it is the right question to ask. The source code, the data, the documentation and the credentials are yours and are handed over on request, without conditions. If you decide to move, the cost is transition work — not a hostage negotiation.
Because there you pay per user for a process model that is not yours, and every adaptation goes through a consultant. Here you start from a complete product and shape it around how you already work. Both approaches are legitimate; they suit different constraints. If your processes are genuinely standard, a subscription is cheaper and you should take it.
We scope first. Then the proposal carries a fixed scope and a timeline. A number given before anyone has looked at your processes is a guess, and guesses are what make projects overrun.
They will. That is why the platform is shaped rather than written: most changes are configuration and extension, not a rewrite.
Sales
The signed figure and the pipeline on the same screen, because a good month and a good quarter are not the same question — and the offers issued line runs ahead of the revenue line by exactly the length of your sales cycle.
Marketing
Nothing is generated from an unapproved plan — not manually, not by a scheduled job. The calendar is where that rule is visible: every activity carries its state, and the ones nobody has approved stay that colour.
Management
Contracts and hosting sit in the same register as the invoices they generate, with the monthly value converted at the day’s rate.
It covers work that would otherwise be split across all three, but calling it an ERP sets the wrong expectation — full statutory accounting stays with your accounting system. The useful description is a business platform: sales, operations, finance, content and commerce in one place.
Laravel and MySQL on the server, with the public front end generated in Astro or Next.js and served as static files. That combination is why a content site scores above 90 on Lighthouse while the admin behind it stays a full application.
Yes. A REST API with scoped keys, a read-only GraphQL endpoint, HMAC-signed webhooks on change, and imports from CSV, XLSX, XML and JSON. Content migrates in from WordPress; catalogues from WooCommerce, PrestaShop and Shopify.
Seven are configured today: English, Romanian, German, French, Italian, Spanish and Hungarian. Content translations are stored one row per language, so adding another is a data question rather than a rebuild.
Roles are set per site, with a capability map behind them. A contributor can request publication; an editor can publish; an administrator configures. Approval is a flow, not a convention.
You take it. Source code, database, documents and credentials are handed over on request. Nothing is stored in a format that only we can read.
