Vendor posture
Security and vendor posture
Last updated: August 3, 2026
What ThynkQ builds
5 current fixed-scope starting points are: Build Readiness Audit, Rescue Sprint, Launch Build, Product Build, and MCP Risk Review. Full scope, pricing, and comparison live on Pricing.
What this page is
If you are running vendor intake on ThynkQ, this page answers the questions on your form. It includes the answers that are no. Nothing here is aspirational and nothing here is a certification we do not hold.
ThynkQ is a senior engineering studio operated by Abanoub Rodolf Boctor in New York, NY. ThynkQ is not a separately incorporated entity. Agreements are currently signed personally. If your procurement process requires a registered counterparty, raise it during scoping. Entity formation can be completed before contract signature.
For the full delivery, proof, and ownership record beyond vendor intake, see the full due-diligence pack.
What we do not have
- No SOC 2 report, Type I or Type II.
- No ISO 27001 certificate.
- No HIPAA attestation, and no Business Associate Agreement in place today.
- No PCI attestation. Card data goes to Stripe directly and never touches our systems.
- No Errors & Omissions (E&O) insurance policy is currently carried. If your intake requires a certificate of insurance, that requirement can be raised during scoping.
- No penetration test report on file for thynkq.com.
If any of those is a hard gate in your process, you have your answer now. Ask before scoping and we will tell you plainly whether it can be met. What is settled: under our Terms, total liability on any engagement is capped at the fees you paid for that engagement, and disputes are governed by the law of the State of New York.
What we touch during an engagement
The default is least access. We ask for what the build needs and nothing adjacent to it.
We ask for
- Repository access, scoped to the repos in the engagement, on permissions you grant and can revoke.
- Staging and development environments.
- Credentials for third-party services in scope, delivered through your secret manager or vault.
- Product, architecture, and API documentation.
We do not ask for
- Production customer records.
- Protected health information, payment card data, or government IDs.
- Standing production database access.
- Employee HR or payroll systems.
Some engagements genuinely need production access. A live incident is the usual reason. When that happens it gets written into the statement of work: what is accessed, by whom, for how long, and how access is revoked at handoff. It does not happen on a verbal ok.
Credentials. Send them through your secret manager, your vault, or a one-time link. Not email, not chat. If you send a long-lived key we will ask you to rotate it and scope it down.
Handoff. At the end of an engagement you revoke our access. Repos, cloud accounts, third-party dashboards. Ask us to confirm what we still hold and we will list it.
Where your project runs
Your project runs on infrastructure in your accounts, under your billing, with your name on it. We build inside your cloud and your repos, not on a ThynkQ platform you would have to migrate off later.
The precedent is PowerLiens. We replaced a paid third-party mapping dependency with map infrastructure the client owns and runs. That work is documented. The subprocessor list below is what thynkq.com itself runs on. It is not your delivery path.
Subprocessors for thynkq.com
The entries below are services this repository identifies in current public-site data paths. They describe thynkq.com, not a client delivery environment.
| Service | Role | What reaches it |
|---|---|---|
| Vercel | Hosting, edge network, cookie-free analytics, and Vercel KV. | Receives standard request logs, including IP addresses. KV stores site controls, rate-limit state, and limited Stripe webhook records. |
| Cloudflare | Worker proxy for the on-site AI chat path. | Receives AI chat requests sent through the configured proxy. |
| Neon | Serverless Postgres behind site features. | When portal features are used: client account, project, invoice, payment, referral, kickoff-brief, and audit data. Not a client delivery environment. |
| OAuth sign-in for the owner and active client portal accounts, when Google OAuth is configured. | Google authenticates the sign-in and returns the verified account identity used for access control. | |
| Groq | Behavior analysis for the optional on-site AI panel, only when GROQ_API_KEY is configured. | Receives a compact browsing-behavior summary when a visitor opens that panel. |
| Resend | Transactional and newsletter email delivery. | Sees the address and body of anything we send you. |
| Stripe | Payments for digital products and paid sessions. | Card data goes to Stripe directly and never reaches our servers. |
| Cal.com | Scheduling for calls booked from /book. | The embed stays unloaded until you ask for it. |
Google OAuth is available only when configured, and it can sign in the owner or an active client portal account. It is not set for ordinary site visitors. Fonts are self-hosted at build time, so no font CDN sees your requests. Full cookie and retention detail is in the Privacy Policy.
NDA, confidentiality, and IP
Mutual NDA. Standard and available on request. We will sign one before project details are discussed, not after. Email and it comes back the same day or the next. If you have your own paper, send it and we will review yours rather than push ours.
Confidentiality. Codebases, roadmaps, and business context stay private. We do not name clients or describe engagements without written consent. 3 delivery relationships back the public claims on this site: a named client engagement, a co-founded product, and one confidential client engagement under NDA. The NDA engagement is not named anywhere on this site, including in the places where naming it would help us sell.
IP assignment. All custom code and deliverables transfer to you on receipt of full payment. You own the product outright, including the right to modify it, hand it to another vendor, or sell it. The precedent is PowerLiens: they own the map infrastructure we built for them, and this studio makes no ownership claim over it.
What we keep. Generic techniques and non-client-specific tooling, the same way any engineer carries their craft between jobs. Nothing proprietary to you, no derived data, no reuse of your code in another engagement.
Deposits, milestones, and stopping early
The deposit term is real and worth stating without softening. The deposit is fully refundable if you cancel before kickoff begins. Once kickoff begins, the deposit is non-refundable. No work starts before the deposit clears.
Here is what actually limits your exposure.
- The trigger is kickoff, not signature. Cancel before kickoff begins and the deposit comes back in full. Once kickoff begins, the non-refundable clock starts and the deposit is spent.
- Payment is milestone-gated. 50/50 on everything up to $59,999. Three milestones on $60,000+ engagements: 40/30/30. On a $30,000 build your exposure before the first delivered milestone is the 50% deposit. On a $60,000 build under the three-milestone split, it is the 40% deposit. Either way it never grows past that, and each later payment is gated on delivered work you have seen.
- There is a cheaper way to test us. The $7,500 Build Readiness Audit runs one week, produces a written risk-ranked report, and the full fee is credited toward a build signed within 60 days. That is the low-commitment path if a $30,000 first engagement is too large a bet on a studio you have not worked with.
- Weekly proof, not a black box. Every week produces shipped changes and an acceptance checkpoint. If week two is wrong, you find out in week two.
We do not publish a termination or wind-down clause today. If your process needs one, raise it during contracting and get it into the statement of work. Do not assume the published Terms cover it, because they do not.
References
3 delivery relationships back the claims on this site. The same set is on the Proof ledger: a named client engagement, a co-founded product, and one confidential client engagement under NDA.
One named reference: PowerLiens. If you want to speak to someone there, ask and we will make the request.
ProTeach is a co-founded product, not a hired-us reference. It was co-founded and built end to end, not delivered for a paying client, so it cannot serve as a reference call. Its public surface is on the Work page, and its numbers are sourced on the provenance audit.
The confidential engagement is under NDA. We cannot name the client, describe the engagement, or publish metrics from it. Numbers that once appeared here were removed because they could not be independently verified.
No testimonials. There are none on this site, and that is deliberate. We do not publish praise we cannot attribute to a named person who agreed to it.
Read the code instead. mcp-scan is our MCP server security scanner, MIT licensed, published on npm with source at gitlab.com/abanoub.rodolf/mcp-scan. Judge the engineering directly rather than taking our word for it.
Requesting a security review
Send your vendor questionnaire to rodolf@thynkq.com. We answer it as written, in writing, so you have something to attach to your intake record. Where the answer is no, it says no. We do not leave a field blank hoping it slides through.
If you need an NDA signed before you can share the questionnaire, say so in the first email and we will send one back before you send anything else.
To report a vulnerability in thynkq.com, email the same address with details and a way to reproduce it. We will confirm receipt and tell you what we did about it.
Changes to this page
This page changes when the facts change, and the date at the top moves with it. If we ever obtain a certification listed above as absent, it will appear here with the report available on request. Until then, treat the absence as accurate.