# A custom business platform shaped around your processes > A custom business platform from Valenys covers 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. Source: https://valenys.com/platform/ Updated: 2026-09-09 --- _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. ## The problem this solves 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.** ## One screen for what usually needs five Sales, operations, finance and hosting in the same place, so the numbers on the dashboard come from the same records the team works in. ## What the platform covers ### Sales and customer relationships 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. ### Operations and finance 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. ### Content and websites, with a page builder 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. ### Commerce 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. [See details](/platform/commerce/) ### Marketing 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. ### AI, with a budget and a log 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. ### Running it 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. ## The day, in the order it has to happen 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. ## A product that is still being built 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. ## What makes it different ### The website and the system are the same system 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. ### One installation, several sites and shops Isolated from one another, administered together. ### Backups are restored, not just taken 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. ### The content model is defined from the panel 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. ## A page builder, and every page in every language 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. ## Objections worth raising early ### “I do not want to depend on a single supplier.” 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. ### “Why not a large SaaS platform?” 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. ### “How long does it take?” 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. ### “What if our requirements change halfway?” They will. That is why the platform is shaped rather than written: most changes are configuration and extension, not a rewrite. ## What was signed, and what is still being talked about 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. ## The month is approved before anything is produced 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. ## What renews, what expired, what it is worth Contracts and hosting sit in the same register as the invoices they generate, with the monthly value converted at the day’s rate. ## Tell us what you have and what it has to do We scope, then quote. ## Frequently asked questions **Is this a CRM, an ERP, or a CMS?** 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. **What is it built on?** 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. **Can it connect to systems we already run?** 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. **How many languages does it support?** 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. **Who can use the admin panel?** 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. **What happens to our data if we leave?** 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.