ScycraftDescribe how your business works. Get the software that runs it.
Scycraft turns your processes, roles, rules and reporting into a real business application — built, tested, deployed, and changed again whenever your business changes.
● Your processes · Your application · Your source code
Illustrative application · not a real company
Two bad options. Then there is a third.
Every business with processes of its own eventually meets the same fork: bend the business to fit the software, or pay for a software project. Scycraft is the third route.
Buy SaaS
“We’ll change how we work to match the product.”
- Fast to start, and genuinely right when the standard product fits
- Your process gets reshaped by someone else’s assumptions
- The gaps get filled with spreadsheets and a second tool
- Per-seat cost grows with headcount, not with value
- You own the data, not the system
Build it custom
“We’ll hire a team and build exactly what we need.”
- It fits the business, because you specified it
- Analysts, architects, designers, developers, testers, DevOps
- Months to a first release, and the documentation is stale by then
- Every later change reopens the whole project
- You own it — including the cost of keeping it alive
Scycraft
“Here is how our business works. Build the software for it.”
- You describe the business; you do not write a technical spec
- Scycraft produces the specification, the application and the tests
- It is deployed and running, not a prototype
- Changing a business rule is a conversation, not a project
- Real source code, in your repository, if you want it
When your business doesn’t fit the software,
build software that fits your business.
The systems your business actually runs on
Scycraft is built for serious line-of-business applications — the ones with roles, rules, approvals, workflows and reporting behind them.
Customers & revenue
- CRM and pipeline management
- Sales and quoting systems
- Customer and partner portals
- Order management
- Contract and renewal tracking
Operations
- Workflow and approval systems
- Case management
- Service management and ticketing
- Field-service scheduling
- Inventory and asset management
Internal systems
- Employee portals
- Recruitment and talent management
- Supplier and vendor management
- Projects, timesheets and billing
- Internal administration tools
Visibility
- Operational dashboards
- Management reporting
- Lightweight ERP capability
- Compliance and audit records
- Bespoke line-of-business apps
Scycraft is not a replacement for every category of software. It is for custom business systems — where your process is the reason off-the-shelf software keeps not quite fitting.
From how your business works to software that runs it
One path, six steps. Business language at every step you take part in; standard software engineering underneath it.
Describe the business
Explain what your company does, who does it, what has to be approved and what has to be reported. Notes, documents, recordings and existing systems all count as input.
Raw inputs are inventoried and extracted — no template to fill in first
Agree the specification
Scycraft writes a plain-language specification of the software your description implies: roles, rules, workflows, data and reports. You read it, correct it, approve it.
Versioned and integrity-checked; an approved specification cannot be silently overwritten
Plan the work
The approved specification becomes an ordered plan of features and tasks, so you can see what is being built, in what order, and what is still open.
Published as a tracked work-item tree in your own Azure DevOps project
Build the application
The application is implemented against one standard, proven architecture: screens, business rules, permissions, data, integrations and reports.
Real C#/.NET source, one convention throughout, generated tests alongside the code
Prove it works
Nothing is called done because it looks done. The application is compiled, the tests are run, the system is started and its endpoints are answered before anything moves on.
Build → unit, architecture and integration tests → live start-up and endpoint checks → recorded report
Release and run
The application is packaged, released through a proper pipeline and deployed to a secured address your people can log into. Then it is watched.
Automated PR → pipeline → container → HTTPS domain; failures raise tracked defects
A new requirement doesn’t start a new project. It goes back to step 02, the specification is updated, and the same path runs again.
You approve the specification
Nothing is built from an understanding you have not read and agreed to.
Every change is reviewed
Changes are proposed for review and never merged automatically. A person accepts them.
Release needs evidence
Work only closes once the merge, the pipeline and the deployment have actually happened.
Your business changes. So does the software.
Most custom software starts accurate and drifts. In Scycraft the specification is not a document produced once and filed — it is the source the application is built from, so changing the business means changing the software.
You do not raise a change request, write a spec, or brief a developer. You say what changed.
Illustrative example. It shows how a change propagates, not customer results.
This is your application, not a configuration in someone else’s platform
Scycraft produces a normal, professional software application. It can live in your repository, be read by your engineers, and outlive your relationship with us.
Real source code
A conventional C#/.NET application with a domain model, an API, a user interface and a database — not a proprietary runtime you can only edit through us.
One standard architecture
Every Scycraft application is built the same way. That is deliberate: a single, well-understood architecture is what makes generation, testing and security dependable.
Your repository
Connect your own GitHub or Azure DevOps. The code, the history and the work items sit in infrastructure your organisation already controls.
Tests, written with the code
Unit, architecture and integration tests are produced alongside the application and run on every change — which is why a business rule can be changed safely later.
Pipelines and deployment
Build and release pipelines, a containerised application and a secured HTTPS address are part of what gets set up — not a separate project afterwards.
Documentation that matches
Because the specification is what the application is built from, the written description of the system and the running system do not drift apart.
C# and .NET, with Azure DevOps or GitHub for source and delivery. Standardising is what makes the rest of this reliable — we would rather do one stack properly than five approximately.
We run it, or your team does
The same application, the same architecture. The difference is who holds the keys afterwards.
We build it and we run it
For businesses without a software team — and no wish to start one.
- We build the application from your description
- We host, deploy and monitor it
- Backups, updates and security patching are ours
- New requirements are handled as ongoing evolution
- You get a working system and a person to talk to
We build it. Your developers own it.
For companies with a technology team who want the speed without the lock-in.
- Connect your own GitHub or Azure DevOps
- The code lands in your repository, under your review
- Your engineers read, extend and take over any part of it
- Use Scycraft to keep delivering features alongside them
- Your pipelines, your environments, your control
What a description turns into
Three illustrative descriptions, and the systems they imply — including what happens six months later, when the business changes.
Illustrative examples, not customer accounts“Sales manages opportunities, consultants submit timesheets, project managers approve them, and finance invoices customers.”
- CRM
- Projects
- Assignments
- Timesheets
- Approvals
- Invoice preparation
- Dashboards
- Roles & permissions
Six months on: “Clients should approve timesheets themselves.” A client portal, an external approval step and a new permission level are added to the same application — not a second system.
“We sell through distributors to outlets. Orders need credit approval, and we need to see what every region is doing.”
- Customers
- Distributors & outlets
- Order management
- Credit approvals
- Payments
- Stock visibility
- Regional reporting
Six months on: “Outlets should place their own orders.” An outlet portal is added on top of the existing order rules, which stay in one place.
“Customers log service requests, we assign an engineer, they update status on site, and we bill on completion.”
- Customers
- Service requests
- Assignment
- Field updates
- Status tracking
- Completion & billing
- SLA reporting
Six months on: “Jobs over GH₵5,000 need a manager to sign off first.” One rule change, propagated through workflow, permissions, data and tests.
Not a SaaS product. Not a coding assistant.
Why not just buy SaaS?
Often you should. When a standard product matches how you work, buying it is the right decision and we will tell you so. Scycraft becomes the better answer when the product keeps not quite fitting.
A finished product, shared by many companies. You adapt your process to it, extend it where it allows, and pay per seat as you grow.
An application shaped around your process, your roles and your rules — in code you can own, changing when your business does.
Why not just use an AI coding assistant?
Coding assistants are good at what they do, and Scycraft is not competing with them for a developer’s editor. They help someone write code. Scycraft is responsible for the whole system existing.
Sits with a developer and helps them write and change code faster. Someone still has to specify, plan, test, release, deploy and maintain the system.
Takes a business description through specification, planning, implementation, testing, release and deployment — and back again on the next change.
Businesses whose processes are the point
You need a system, not a project
Your operation runs on spreadsheets, email threads and a SaaS tool that half fits. You want the software your business actually needs, without hiring a department to get it.
Founder · CEO · COO · Operations Director · Business Unit Lead
You need delivery speed without lock-in
You have a backlog longer than your team and no appetite for a platform you cannot read. You want real source code in your repository, on an architecture you can audit.
CTO · CIO · Head of Engineering · Software Architect
You build these systems repeatedly
You deliver line-of-business systems for clients and rebuild the same foundations each time. Standardise the delivery, hand over a clean codebase, keep the client relationship.
Delivery Lead · Practice Lead · Implementation Partner
What exists today, and what doesn’t
Scycraft is in private preview. Rather than describe the finished product, here is the honest state of each capability. Anything marked in development or planned is not something you can rely on yet.
| Capability | What it means | Status |
|---|---|---|
| Business description → specification | Your inputs become a versioned, approved specification with prior versions kept | Available |
| Specification → plan and work items | Features and tasks published into Azure DevOps as a tracked work-item tree | Available |
| Application generation | A complete C#/.NET solution: domain, API, gateway, web front end, database | Available |
| Automated verification | Build, unit, architecture and integration tests, live start-up and endpoint checks | Available |
| GitHub & Azure DevOps | Connect your own repository and project; code and work items live there | Available |
| Pipelines & deployment | Generated build/release pipelines, containerised deployment, HTTPS domain | Available |
| Monitoring → defect → fix | Production issues raise tracked defects that go through reproduce, fix and verify | Available |
| Managed builds with Scycraft | We take your description and deliver the application as a managed engagement | Private preview |
| AI workspace | The browser workspace at app.scycraft.com, with accounts, credits and metered usage | Private preview |
| Self-service application builder | Describing your business and getting an application without us in the loop | In development |
| Isolated build environments | Every project built and tested in its own sealed environment with enforced limits | In development |
| Additional cloud targets & private deployment | Deploying into your own cloud subscription or on-premise environment | Planned · by consultation |
Automation with a person in charge of it
Business systems hold your customers, your money and your obligations. Nothing consequential happens without a human deciding it should.
The application is yours
Under an engineering engagement the source code sits in your repository, on your accounts. You are not renting access to your own business system.
Approval where it matters
The specification is approved by you before anything is built, changes are proposed for review rather than merged, and work only closes on evidence.
From requirement to release
Every change traces back to the requirement that caused it, through the work item, the code change, the test results and the deployment that shipped it.
Scoped permissions
Access to repositories, project tools and environments is bounded by the permissions you grant, and can be limited per project and withdrawn.
Only what a request needs
Only the code and context needed to carry out an authorised request are sent to the configured AI service. Scycraft works with OpenAI-compatible models, so that service can be chosen to suit your requirements.
You see what it costs to run
Hosting and usage are shown separately from the build and management fee, so the cost of running your application is visible rather than buried.
Questions about data handling, source-code ownership, security or a private deployment model? Ask, and we will tell you exactly what is supported today and what is not.
Ask about security & ownershipPriced like a system, not a seat
A build, then an ongoing relationship. Commercial terms are agreed per engagement during private preview — we would rather quote your application than publish a number that fits nobody.
- Application built from your description
- Hosting, deployment and monitoring
- Backups, updates and security patching
- Ongoing changes as your business evolves
- Infrastructure billed transparently
- Your GitHub or Azure DevOps
- Full source code and history
- Generated pipelines and tests
- Continued delivery alongside your team
- Your environments and your control
- Identity and single sign-on integration
- Audit, governance and approval controls
- Private and self-managed deployment
- Custom architecture requirements
- Implementation and training
- AI assistance in the browser
- Account, credits and usage tracking
- Free daily allowance
- Prepaid passes, no subscription
- Local currency in supported markets
Local pricing, local currency, Mobile Money checkout and local invoicing are available in supported markets, including Ghana. Students and learners can use the workspace on a GH₵50 Student Pass. Ask us what applies in your region.
Ask about regional pricingThe questions people actually ask
What exactly do I get?
Do I need to know anything technical?
Is this a no-code platform?
What happens when my business changes?
Can my own developers work on it?
Why only C# and .NET?
Where does the application run?
Does an AI change my software without anyone checking?
How long does a first application take?
What does it cost?
What if I want to stop using Scycraft?
I am a student or an individual developer — can I still use Scycraft?
How do I start?
Tell us what you need built
A few sentences about your business and what isn’t working is enough to start. We are taking on a small number of build partners during private preview.
Have an access code for the workspace? Enter the workspace →