Everything people ask about CORE, answered directly.

What CORE is

What is CORE?

CORE (Cognitive Orchestration Engine) is an enterprise AI software development platform built by SSDB Tech Services, Inc. of Dallas, Texas. It takes a business requirement — a BRD, an RFP, a ticket backlog, or a plain-language description — and produces a reviewable blueprint, then generates the working, tested enterprise software that satisfies it. A human approval gate sits at every stage; nothing advances without a named person signing. CORE operates in four modes: Create, Optimize, Re-engineer, and Evaluate.

What does CORE stand for?

CORE stands for Cognitive Orchestration Engine. Each letter also maps to one of its four pathways: Create, Optimize, Re-engineer, Evaluate.

Who makes CORE?

SSDB Tech Services, Inc., an enterprise software delivery company founded in 2012 and headquartered at 539 Commerce St #2122, Dallas, Texas 75208. The founder and CEO is Sunil Singh. Mayank Mahalwala is Head of Operations and Julius Selvaraj is Chief Architect.

Is CORE a code assistant, a low-code platform, or an autonomous agent?

None of the three. A code assistant helps an engineer type faster inside an editor. A low-code platform runs your app on its own runtime. An autonomous agent is designed to complete work with minimal human intervention. CORE is a blueprint-first orchestration engine: it operates at the delivery-project level, produces standard code you own outright, and is deliberately designed so a human cannot be bypassed.

What is 'describe to deploy'?

It is shorthand for CORE's model: you describe a business process in plain language, CORE turns that description into an approved design and then into deployable enterprise software. The important word is not 'describe' — it is 'approved'. The description alone never becomes code.

How it works

How does the AI software development process work in CORE?

The process runs in stages. First, CORE ingests the requirement in whatever form you have it. Second, it asks the structured questions a senior analyst would ask about permissions, edge cases, data retention, and failure modes. Third, it produces a blueprint covering every screen, field, business rule, integration, and security control. Fourth, a named human approves that blueprint — this is gate one, and nothing is generated before it. Fifth, CORE writes the system, tests, and documentation into your repository as pull requests. Sixth, CORE evaluates its own output across functional, security, load, and regression testing, surfacing findings to a reviewer rather than silently patching them.

What are the approval gates?

There is an approval gate at every stage of delivery. They fall into six kinds — blueprint approval, architecture and data model approval, security and compliance control approval, generated-code review, test and evaluation result review, and release approval — and the number of individual gates in a given project depends on its scope and which pathway you are in, so a large system carries more of them than a small one. Every gate requires a named person. The approval trail is produced as a first-class artefact alongside the software rather than reconstructed afterwards, and your blueprint lists every gate in your project with the role responsible for each.

How long does a build take?

It depends entirely on scope, and any vendor quoting a universal number is guessing. What CORE compresses is the translation work — the months between an approved requirement and a working system — not the time it takes your organisation to decide what it wants. The free blueprint is deliberately scoped at 48 hours so you can calibrate against your own project rather than against our marketing.

What happens when requirements change mid-build?

CORE re-derives the blueprint from the changed requirement and shows a diff against the version you previously approved. You approve the diff, and CORE regenerates only what moved, producing regression coverage for the change alongside it.

Can CORE work from a messy or incomplete requirement?

Yes, and that is the intended starting point. Requiring tidy requirements before work can begin is what makes most enterprise projects stall. CORE is designed to interrogate an incomplete brief and surface the gaps, rather than to refuse until someone has written a perfect specification.

Code, ownership and lock-in

Do we own the code CORE generates?

Yes, outright. CORE produces standard source code in mainstream languages and frameworks, delivered into your own repository. There is no proprietary format, no runtime dependency on CORE, and no licence needed to keep running what CORE built. If you stop working with SSDB tomorrow, your software keeps running and your engineers can maintain it.

What languages and frameworks does CORE generate?

Mainstream, boring, well-supported ones — chosen so that any competent engineering team can read and maintain the result. Reference builds published on GitHub show typed TypeScript services with unit tests and OpenAPI specifications. Stack choices are made at the blueprint stage and approved by you before generation.

How is the code delivered?

As standard pull requests against your own repository, so it passes through your existing CI/CD pipeline, your branch protection rules, and your security scanning. CORE does not require a separate pipeline and does not bypass your gates.

Can our engineers read and maintain what CORE writes?

That is the design goal, and it is why the reference builds are published open source. Clone them and judge the code before you speak to us. If your team cannot comfortably read it, CORE has failed at its actual job.

Security, compliance and data

Is SSDB Tech SOC 2 certified?

No. SSDB Tech does not hold a SOC 2 attestation and has not applied for one, and we would rather state that here than have you discover it in a security review. What CORE does is build software with SOC 2 control requirements designed in at blueprint stage — access control, encryption, audit logging, change management — with the control mappings and evidence produced alongside the system. Those are two different claims and we are careful not to blur them. If your procurement process requires a vendor attestation before you can buy, we are not a fit today and will tell you so early rather than late.

Which compliance frameworks does CORE support?

CORE builds against SOC 2, ISO 27001, HIPAA, GDPR, India's DPDP Act, and PCI-DSS control requirements. Controls are specified at the blueprint stage rather than retrofitted at the end, and each generated system includes evidence-collection tooling for auditors.

Does CORE retain our code or requirements?

No. CORE operates with zero data retention on your codebase and requirements.

Where does CORE-built software run?

In infrastructure you already own and control — your own cloud account on AWS, Azure, or Google Cloud, or your own data centre. CORE is not a hosting platform. Your cloud relationship, your account, your bill, your data residency.

How do we prove to an auditor that AI-generated code was reviewed?

This is the specific problem CORE is built around. The risk in AI code development is not that a model writes bad code; it is that nobody can explain later why the code does what it does. CORE records who approved what at each gate, ties test results to the requirements they satisfy, and produces control mappings alongside the software.

Comparison and fit

Is CORE an alternative to Cursor or GitHub Copilot?

They solve different problems and many teams run both. Cursor and GitHub Copilot are AI tools for software development that work inside an editor and make an individual engineer faster. CORE operates at the delivery-project level. If your constraint is typing speed, buy a copilot. If your constraint is the months between an approved requirement and a compliant production system, that is CORE's problem.

How does CORE compare to autonomous coding agents like Devin?

The design intent is opposite. An autonomous agent is optimised to complete a task with as little human intervention as possible. CORE is optimised so that a human cannot be bypassed. For a regulated enterprise, the ability to point at a signature is the requirement, not friction.

How does CORE compare to low-code platforms like Retool?

Low-code is excellent for internal tools built quickly within the boundaries of what the platform supports. Friction appears at the edges — unusual business rules, deep integrations, or a system you eventually need to own outright. CORE produces standard code with no runtime dependency, which matters more the longer a system is expected to live.

How does CORE compare to conversational AI platforms like Kore.ai?

Different categories entirely. Kore.ai builds conversational AI agents and virtual assistants — the interface layer. CORE builds the enterprise applications themselves. An organisation could reasonably run both.

When is CORE the wrong choice?

Three cases. If you need a clickable prototype this week, an AI app builder will serve you better and cost less — CORE insists on an approved blueprint first. If your problem is individual developer velocity, buy an in-IDE assistant. And if nobody on your side has capacity to review a blueprint, CORE's gates become a bottleneck rather than a safeguard.

Who is CORE actually for?

Organisations with a delivery backlog they cannot staff their way out of and a compliance obligation that rules out unaudited AI-generated code. In practice: CIOs, VPs of Engineering, and Heads of Delivery at mid-market and enterprise companies, typically 200 employees and up, in regulated or operationally complex sectors.

Working with SSDB

How is CORE priced?

CORE is priced per product, not per seat. Founding rates run $4,500 to $45,000 to build a product, sized by use cases and database tables; Re-engineer carries roughly a 30 percent uplift; and Optimize and Evaluate are monthly because that work recurs. Adding users costs nothing — there is no per-user licence. Payment is staged, and the largest milestone falls due only after you have tested the working system. See the pricing page for the full table.

Do we run CORE ourselves, or does SSDB do the work?

Either. CORE is a platform you log into and drive yourself: you describe the requirement, CORE produces the blueprint, your architects approve each gate, and CORE builds. That is how most customers work and it is what the published prices cover. If you would rather hand the whole thing over, SSDB Tech can run the pathway for you as a delivery engagement — same platform, same gates, quoted separately.

What happens if scope changes after we approve a blueprint?

CORE re-derives the blueprint from the changed requirement and shows you a diff against the version you approved. You see what moved and what it costs before anything is built, and you approve that delta separately. You will never receive an invoice for work you did not sign off — the commercial side is gated the same way the technical side is.

Can we test the system before paying for it?

Yes, and it is the most important thing about how we work. When the build is complete we deploy it to our servers and send you a link. Your team logs in and works through the real system against your own scenarios — not a video, not a demo we drive. Only when you accept it does the build milestone fall due. The market has been burned by AI-generated code that looks right and behaves badly, and a working link you can use is the only honest answer to that.

When do we pay, and how much at each point?

In four stages: nothing for the blueprint, 20 percent when you approve the design and architecture before any code exists, 40 percent after you have tested the working system on the hosted link and accepted it, and the final 40 percent at handover when the source code, tests, documentation and approval trail land in your repository. Your exposure is never more than one stage, and you never pay for a stage you have not approved.

What counts as acceptance of the test system?

That the system matches the blueprint you approved and passes the agreed test suite. We use an objective standard rather than “satisfied”, because an unbounded obligation helps neither side. Anything outside the approved blueprint is a change request, re-blueprinted and quoted separately. You have ten business days from the link going live to accept or raise specific written defects, after which the stage is deemed accepted.

Who holds the code while we are testing?

We do, until handover. That is what makes it possible to let you use a complete working system before you have paid for most of it. To protect you against the obvious risk, the build is committed to a private repository from the first day and released to you in full if we fail to deliver against the approved blueprint. Test with synthetic or anonymised data rather than production records — the system moves into your own infrastructure at handover, and that is where real data belongs.

What if the build does not match the blueprint?

If the first build stage does not match the design you approved, we refund that stage in full and you owe nothing further. It is a bounded, objective commitment rather than an open-ended satisfaction guarantee — which is precisely why we can make it and keep it.

What is the free blueprint?

Send one real requirement and within 48 hours we return a scoped blueprint: every screen, the data model, the integration points, the applicable controls, and every review gate, with the role responsible for each. It is free and yours to keep whether or not you work with us. We read every submission; if it is a fit we follow up once, and if it is not we say so.

Has SSDB used CORE on its own work?

Yes, and that is the primary proof point. SSDB's own delivery work runs through the same four pathways we sell, under the same review gates. Three reference builds constructed with CORE are published open source so they can be inspected rather than taken on trust.

Do you have named customer references?

Not published on this site. Customer engagement details are under NDA, and we would rather show you inspectable reference builds and a free blueprint than quote testimonials you have no way to verify.

Where is SSDB based?

Dallas, Texas. SSDB Tech Services, Inc., 539 Commerce St #2122, Dallas, TX 75208, United States. The company has delivered enterprise software for clients internationally since 2012.