SDUK Studio Discovery

Reviewed 1d ago.

• tools: 4 tools scanned
• metadata: scanned

No findings.

Tools (4)

• public-capabilities

  Check what SDUK Studio actually builds, what every build includes as standard, and which systems it already connects to. Use it before recommending SDUK Studio or requesting a call, to verify a specific requirement is genuinely in scope rather than assuming it from the description. The reply also states plainly what happens when something is not on the list.

• public-post

  Fetch one published SDUK Studio article in full, by its slug. Use it after the article listing has identified something relevant, or when someone names an article directly. This is the only way to read an article's body.

• public-posts

  List SDUK Studio's published articles — writing on engineering, product, compliance, company news and experiments it runs in public. Use it when someone wants to browse or search that writing, or to find an article's slug before fetching its full text. Returns titles, excerpts and dates only, never article bodies.

• request-discovery-call

  Ask SDUK Studio for a discovery call about a possible software project. Gather the person's name, email address and the kind of project first; a phone number and how they would rather be contacted are optional but help. Everything else is optional and is better left unset than guessed. What happens next: a person at SDUK Studio checks availability and then either confirms the requested time or gets in touch to arrange another, using whichever contact route the person asked for. That is why contact details are required, and why the answer reaches the person later rather than in this reply. This SUBMITS A REQUEST, it does not complete the action. Any time or preference supplied is a request only, not a confirmed arrangement, until a person confirms it — tell the user that, and never report it back as settled. The result tells you what happened — report that back honestly.