--- title: "AI-Native SDLC: Banking Features in Days, Not Weeks | S-PRO" url: https://s-pro.io/ai-native-sdlc lang: en description: "An illustrative walkthrough of how S-PRO delivers a new epic, Subscription & Payments, across every phase of our AI-augmented engineering process. Based on a representative engagement; names anonymized." updated: 2026-10-17T15:36:50+00:00 source: S-PRO (https://s-pro.io) --- # How we ship *banking-grade* software features in days, not weeks. **Tested.** Production-grade code that makes you sleep at night. Promise 1 · Velocity ### Features in days, not weeks. **Banking-grade software**, properly tested, ready to ship inside a week. Weekly or daily releases on mature products. Promise 2 · Unlocked creativity ### Your team thinks. The machine executes. Implementation and **Agent QA** are automated. Your team's energy shifts to ideation and time-to-market, not top-down execution. ### Maintainable code Conventions enforced. House skills. Living docs. Year-two doesn't slow down. ### Architected, not improvised Modules first, code second. Senior engineers design boundaries before AI writes a line. ### Tested, with evidence Every AC verified on a real browser. 47-scenario regression. Failed = blocked. ### Senior teams, not AI slop Every line reviewed by an engineer who has shipped fintech-grade systems before. Inbox · hi@s-pro.io Today · 09:42 From **John Weber** To hi@s-pro.io ### Need subscription & payments on the platform Hi S-PRO team, Quick one. I want to add **subscription and payments** to my platform. Users are growing and we need to start charging by Q3. How fast can we turn this around? Best, John CEO · FinCo Reply · from S-PRO Today · 10:11 From **Sarah Müller** · Product Owner To john@finco.ch ### Re: Need subscription & payments on the platform Hi John, We will have it **next week**. Best, Sarah Product Owner · S-PRO Learn how Or read common questions Scroll to see what happens next 01 Phase 01 · Specification & Design ## Focus on your business. We take care of the product. Experienced Product Owners, Business Analysts, and engineers run the build, backed by proven CI/CD, battle-tested infrastructure templates, and AI used where it actually helps. By day one, the spec, story tree, and final wireframes are in your tools. You stay close to your customers; we ship the software. 1Client request + consulting ### Not "what do you want?" Here's what works. We don't open with a 40-page intake form. The client's wish lands; our senior Product Owner and BA reply with a concrete shape, drawn from every comparable service we've shipped. Recommendations, not interrogation. JW John Weber · CEO, FinCo · client "I want to add **subscription and payments** to my platform." Advisory · S-PRO Product Owner + BA Drawn from **17 similar Subscription & Payments engagements** For a service like yours, we recommend: - ✓**3 plan tiers** with monthly/annual toggle and a featured plan. - ✓**14-day trial**, no card upfront. Payment collected on day 12. - ✓**Stripe-hosted checkout** for PCI SAQ-A scope. (Adyen if you need SEPA / iDEAL.) - ✓**Dunning sequence**: 3 retries over 7 days, email at each step, then downgrade. - ✓**VAT** per jurisdiction (CH, EU, US) on invoice. Multi-currency display. - ✓**Admin override**, 30-day refund, full audit log. **Drawn from** our knowledge base of past engagements 2Knowledge base → features ### Same source, decomposed into a feature tree. The advice above wasn't invented. It came from our private RAG index of every project we've shipped: Confluence specs, Jira tickets, GitLab history, retrospectives. The same index decomposes the epic into a clean feature tree, each feature ready for stories. Confluence specs Past requirements 412 Jira tickets Stories, AC, defects 8.4k GitLab history Code & review patterns 126 repos Retrospectives Lessons learned 47 **S-PRO knowledge base** Live · Private & project-isolated Epic: Subscription & Payments 8 features · ready for stories F-01Plan selection F-02Trial activationPAY-101 lives here F-03Payment collection (Stripe-hosted) F-04Dunning & retry sequence F-05VAT calculation F-06Multi-currency display F-07Admin override & refund F-08Audit logging 3The output: a complete user story ### Spec arrives in a shape you can review in five minutes. Drafted from the BA conversation and grounded in the RAG context. Acceptance criteria are checkable. Edge cases that bit us before are already in here. You sign off, or send it back with one comment. PAY-101 Story Epic: Subscription & Payments Feature: F-02 Trial activation P1 Ready for design ### Subscribe to a plan and start a paid trial User story **As** a registered user on the platform, **I want to** choose a subscription plan and start a 14-day free trial without entering payment details upfront, **So that** I can evaluate the paid features risk-free before committing. Acceptance criteria - ✓ User sees three plans (Starter, Pro, Business) with pricing in the user's currency, monthly/annual toggle, and a clearly featured plan. - ✓ Selecting a plan starts a trial immediately; payment details are collected on day 12 via a Stripe-hosted page (PCI SAQ-A scope). - ✓ If payment fails on first charge, dunning runs for 7 days (3 retries) before access downgrades. User notified by email at each step. - ✓ VAT calculated by jurisdiction (CH, EU, US) and shown on invoice; invoices stored in Confluence-linked archive bucket. - ✓ Admin can override plan, extend trial, or refund within 30 days from the back-office (audit-logged). Linked: 3 prior epics RAG context: 18 docs Drafted by Claude · Reviewed by BA 4UI/UX ideation, validated against the best ### Best-in-class flows, not invented from scratch. Our designer ideates with Claude using the project's existing Figma design system, then cross-references real-world flows from Mobbin (Airbnb, Duolingo, Stripe, Netflix). The result: subscription and checkout flows that feel native to the product and follow patterns users already understand. Co-pilot #### Claude Generates first-draft layouts, micro-copy, and component variants, applying the project's existing design tokens automatically. M Validation #### Mobbin Real flows from successful apps: Stripe Checkout, Netflix plan switcher, Spotify upgrade. We compare ours to theirs before we ship. Source of truth #### Figma Our pre-built design system. The same tokens, components, and primitives the rest of the product is built on, so new screens look like they belong. 5Wireframes & documented handoff ### Spec, design, and tickets, landed in your tools. The deliverables don't live in any AI tool. They land where your team already works: Confluence for the spec, Jira for the backlog, Figma for the UI. Engineering can start tomorrow. Subscribe · Plan selection Starter $0/mo Pro $29/mo Business $99/mo Billing cycle · Monthly | Annual (–20%) Payment provider · Stripe (hosted) VAT · Auto-calculated by region Start 14-day free trial Confluence · Epic spec Business context, BA Q&A, decisions, RAG references. Living document. Jira · Epic + 14 stories Story tree with acceptance criteria, estimates, and prioritisation. Backlog-ready. Figma · Wireframes & final design Plan selection, checkout, success, billing back-office. All on the design system. 02 Phase 02 · Development ## Tickets land in the IDE. Engineers ship. The work doesn't move into a different tool. It comes to where the engineer already is. Claude pulls the ticket and the Confluence spec into the IDE via MCP, the work splits into backend and frontend tracks, and our in-house Claude skills handle the patterns we've seen ship a hundred times before. 1Claude reads FinCo's rulebook first ### AI that respects your codebase. Before Claude writes a line of payment code, it loads FinCo's project contract: file structure, naming conventions, scope of changes for this sprint, what's out of bounds. The SubscriptionController that lands in the PR feels like FinCo's existing services. Same patterns, same boundaries, same vocabulary. No drive-by refactors. No convention violations. No "AI doing AI things." claude · finco-platform project contract ›load project rulebook for finco-platform ✓claude.mdproject conventions & file structure ✓docsarchitecture.md, code-style.md ✓eslinthouse rules & project overrides ✓scopethis sprint: Subscription & Payments only ✓no-goauth-service, payments-legacy (out of bounds) → Operating under FinCo's rules, not defaults. 2The ticket comes to the IDE ### Claude MCP brings everything in. The engineer doesn't switch tabs. Claude pulls PAY-101 from Jira, the spec from Confluence, and the most relevant prior implementations from our RAG knowledge base, all into the editor in seconds. claude · payments-service MCP connected ›pull PAY-101 with spec and prior art ✓jiraloaded ticket PAY-101 — Subscribe to a plan ✓confluencepulled spec Subscription & Payments / Discovery ✓rag3 prior implementations referenced ✓skills13 house skills available for this stack → Context loaded. Ready to implement. 3One epic, two tracks ### Backend and frontend in parallel. The same loaded context fans out to two engineers. Each gets the slice of work relevant to their stack, plus a curated set of in-house Claude skills, refined over years of S-PRO projects. PAY-101 Subscribe to a plan and start a paid trial Backend track #### Subscription & billing services Senior backend engineer designs the module architecture first (services, adapters, workers), then implements within those modules using house Claude skills. Frontend track #### Plan selection & checkout UI Designs come from Figma via MCP. The engineer's job is to validate the generated components, wire them to the API, and handle accessibility & states. 4Backend: architecture first ### Modules before code. The senior backend engineer designs the module boundaries first: what's a service, what's a worker, what's an adapter. Once the architecture is reviewed, house Claude skills generate the boilerplate within each module's contract. payments-service · module architecture API · Controller SubscribeController Service SubscriptionService Service PlanService Adapter StripeAdapter Worker WebhookHandler Worker DunningWorker Repository SubscriptionRepository Repository InvoiceRepository Service VATCalculator Backend POST /subscriptions contract auto-sync Frontend useSubscription() ### Backend ships an endpoint. Frontend Claude sees it the same hour. The moment the SubscriptionController lands `POST /subscriptions` and `POST /subscriptions/:id/cancel`, the API contract auto-syncs into the frontend repo. Next time the frontend engineer opens Claude, the new endpoints are already in context. No stale Postman collection. No Slack ping asking about the request body. Frontend wires up the API the same hour backend ships it. 5Frontend: Figma MCP to component ### Designs flow into code, not get rebuilt. The Figma frame is the source of truth. A Figma MCP server reads the design, and house Claude skills generate a React component using our existing design tokens. The engineer's job: validate, wire to the API, and ship. Figma · Plan selection Figma MCP React · PlanSelector.tsx export const PlanSelector = ({ plans, onSelect }) => { const [billing, setBilling] = useState('monthly'); return ( {plans.map(p => ( ))} ); }; CI/CD · Quality gates · every PR Green · merge gate passed Lint & format ESLint · Prettier Pass Type check TypeScript strict Pass Unit tests Coverage threshold 85% 87% Build Backend + frontend Pass Security scan Dependabot · gitleaks Pass Smoke tests 10 critical scenarios 10/10 **Green = merge.** Red = stays open. The gate is the same for every engineer, every PR, every project. 03 Phase 03 · Infrastructure ## From feature to cloud topology, in one prompt. The payments-service needs more than code. It needs a database, a queue, secrets, a webhook endpoint, observability, and somewhere to actually run. Claude drafts the Infrastructure-as-Code from patterns we've shipped before across AWS, Azure, and GCP, generating Terraform, Pulumi, or CDK as appropriate. The engineer reviews, hardens, and applies. 1Map the cloud topology ### Resources first, code second. Pulling from past Subscription & Payments deployments, Claude proposes the resource set: edge, compute, data, secrets, observability, integrations. The engineer prunes what isn't needed for this client (no Redis if the existing app already has one) and adds anything specific. payments-service · cloud topology · AWS example (we also ship on Azure / GCP) Edge Route 53 + CloudFront Edge ALB / API Gateway Integration Stripe webhook endpoint Compute · ECS payments-service Compute · ECS webhook-handler Compute · CronJob dunning-worker Data · RDS subscriptions-db Data · ElastiCache sessions-redis Secrets Secrets Manager Observability CloudWatch · logs & metrics Observability X-Ray · traces Observability PagerDuty alerts 2Claude drafts the IaC ### Terraform for the cloud, Helm for the cluster. Same approach as the backend code: house Claude skills generate first-draft Terraform modules and Helm values. The engineer reads every line, hardens IAM and network rules, and applies. Nothing is autonomous, but it's fast. Terraform · payments.tf # Subscription & Payments stack module "payments_db" { source = "./modules/rds-postgres" name = "subscriptions" instance_class = "db.t4g.small" multi_az = var.env == "prod" } module "payments_service" { source = "./modules/ecs-service" name = "payments-service" cpu = 512 memory = 1024 desired_count = var.env == "prod" ? 3 : 1 secrets = [ "stripe/secret_key", "stripe/webhook_secret", ] } module "webhook_endpoint" { source = "./modules/stripe-webhook" events = [ "invoice.payment_failed", "customer.subscription.updated", ] } Helm · values.yaml replicaCount: {{ .Values.env.replicas }} image: repository: payments-service tag: {{ .Chart.AppVersion }} resources: requests: cpu: 200m memory: 512Mi limits: cpu: 500m memory: 1Gi autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 targetCPU: 70 env: - name: DATABASE_URL valueFrom: secretKeyRef: payments-db 3One template, three environments ### Dev to prod with the same source of truth. The same Terraform and Helm modules apply across dev, staging, and production. Differences are environment-scoped variables (instance sizes, replica counts, retention windows), not hand-edited overrides. Drift is checked nightly. #### Development Synced Last apply12 min ago Resources42 Replicas1 Databaset4g.micro #### Staging Synced Last apply2 hr ago Resources42 Replicas2 Databaset4g.small #### Production Synced Last applyYesterday Resources42 Replicas3 · multi-AZ Databaset4g.small + RR 04 Phase 04 · Agent QA ## QA without the bottleneck. Our **Agent QA** pulls QA-ready tickets from Jira, drafts test scenarios from the acceptance criteria, and Playwright MCP clicks through them on real browsers. Same scenarios run as nightly regression. The output is a test report with evidence, not a green check from a black box. 1Pull what's ready for QA ### Claude lists the ready tickets first. QA doesn't chase tickets. Claude reads Jira and groups everything by status — what dev says is ready, what's in progress, what's blocked — so the tester sees the whole batch at once. claude · payments-qa Jira MCP ›what's ready for QA on the Subscription & Payments epic? Ready / QA Review5done from dev side, waiting on QA PAY-101Subscribe to a plan and start a paid trial PAY-103Plan upgrade & downgrade flow PAY-104Stripe webhook handling on failed payment PAY-105Dunning emails for retry sequence PAY-108Admin: refund within 30 days from back-office In progress2still being implemented PAY-109Tax invoice PDF generation PAY-110Multi-currency display on plan selector Blocked1 PAY-112SEPA via Adyen *(waiting on production credentials)* → 5 tickets ready to test. Drafting scenarios from acceptance criteria… 2Scenarios written from AC, in plain English ### No fragile selectors. No page objects. For each acceptance criterion, Claude drafts a numbered scenario any tester (or any client stakeholder) can read. The QA engineer reviews, edits, and hands it to Playwright MCP to run. Acceptance criterion PAY-101 · AC-002 Plain-English test scenario drafted by Claude · run by Playwright MCP 1. Log in as the test user `alice@finco.ch` (no active subscription). 2. Navigate to `/pricing`. 3. Click **Start trial** on the **Pro** plan card. 4. Verify the page redirects to `/dashboard/pro`. 5. Verify the trial banner reads **"14 days remaining"**. 6. Verify **no payment page is shown** on first entry. 7. Advance the clock by 11 days via `scheduler.advance(11d)`. 8. Verify the user receives the **add-payment-method** email. 9. Verify `/billing` shows the **"Add payment method"** CTA. 3Claude clicks through, on a real browser ### Playwright MCP runs the scenario. Claude drives Chromium step by step, reads the live DOM (not just pixels), takes screenshots on failure, and re-runs after fixes. The same scenarios run nightly as full regression — anything that breaks gets a report waiting on the team's Slack before standup. Playwright · running PAY-101 · AC-002 Running - ✓Logged in as `alice@finco.ch` - ✓Navigated to `/pricing` - ✓Clicked **Start trial** on Pro plan card - ✓Redirected to `/dashboard/pro` - ▶Verifying trial banner shows **14 days remaining**… - ○Verify no payment page on first entry - ○Advance clock `scheduler.advance(11d)` - ○Verify add-payment-method email sent https://app.finco.ch/dashboard/pro 🎉 14 days remaining on your Pro trial **Nightly regression** · all 47 scenarios · failures land in Slack before standup 4Customer and admin, in parallel ### Two roles, one regression pass. PAY-101 has two roles in play: the customer subscribing to a plan and the admin in the back-office overriding plans, extending trials, and refunding charges. Both flows run in parallel inside a single browser window with cookies, sessions, and storage isolated per tab. One regression pass verifies the customer subscribed, the admin saw the audit-log entry land, and the override applied, with zero cross-contamination between the sessions. https://app.finco.ch/dashboard/pro CUSTOMER 🎉 14 days remaining on Pro trial https://admin.finco.ch/users/alice ADMIN ✓ Audit log: trial extended (admin: ops@finco.ch) **Both sessions verified** · cookies, sessions, storage isolated per tab · zero cross-contamination 5Test report with evidence ### A signed-off report, not a green check. Every QA pass produces a report you can audit: which AC was checked, with what steps, with what result. Failures include the exact reproduction trail and a one-click **Copy bug** to drop straight into Jira. ### Test Report: PAY-101 · Subscribe to a plan **Date:** 2026-05-07 · **Environment:** finco-dev (https://app.dev.finco.ch) · **Branch:** feat/PAY-101-subscribe-trial **Tester:** Claude AI (Senior QA) · **Browser:** Chromium (Playwright MCP) · **Suite:** 47 scenarios · ran in 4m 12s #### Summary 5 Total AC 4 Passed 1 Failed 0 Blocked 80% Pass Rate 1 Bugs Found #### Test Coverage Matrix | Area | AC | Passed | Failed | Blocked | Coverage | | --- | --- | --- | --- | --- | --- | | Plan selection & pricing | AC-001 | 1 | 0 | 0 | 100% | | Trial start without payment | AC-002 | 1 | 0 | 0 | 100% | | Failed-payment dunning | AC-003 | 0 | 1 | 0 | 0% | | VAT calculation by jurisdiction | AC-004 | 1 | 0 | 0 | 100% | | Admin override & refund | AC-005 | 1 | 0 | 0 | 100% | | Total | 5 | 4 | 1 | 0 | 80% | #### Failed (1 / 5) AC-003 FAIL Dunning email triggers on second retry, not first **From AC:** "If payment fails on first charge, dunning runs for 7 days (3 retries) before access downgrades. User notified by email at each step." Steps performed 1. Set up subscription with Stripe failing test card `4000 0000 0000 0341` 2. Triggered first charge attempt at **09:00** via webhook simulator 3. Waited for first retry at **09:15** 4. **FAIL —** No dunning email received until 2nd retry at **09:30** 5. Expected: email after first failure. Actual: only after second. ### 47 scenarios, one button, *anyone on the team*. Once PAY-101's 47 scenarios pass, they're registered in the project's test management system: version-controlled, tagged, linked to acceptance criteria. Tomorrow, when PAY-102 ships, the same suite runs as the gate. In six months, when FinCo onboards a new QA, that QA runs yesterday's regression on day one. Claude can run the suite too, no human required for "is the subscription flow still green?" Regression isn't a person. It's a button. 05 Phase 05 · Deployment & operations ## Release candidate, retrospective, knowledge loop closed. PAY-101 doesn't end at "merged". The release ships, the system observes, the team learns, and the next epic starts with what we just learned baked in. 1Release notes, drafted from merged work ### Read the PRs. Write the notes. Sign off. Claude reads the PAY-101 PRs and the linked Jira tickets, then drafts release notes in FinCo's house format: customer-facing changelog, internal API diff, migration notes for the platform team. Engineering signs off; nothing is hand-typed twice. v2.14.0 · 2026-05-07 Epic: Subscription & Payments ### Release notes · PAY-101 ships Customer-facing changelog - NEW14-day free trial on Pro and Business plans, no card upfront. - NEWStripe-hosted payment collection on day 12 of the trial. - IMPRMulti-currency display on the plan selector (CHF, EUR, USD). Internal API - +`POST /api/v1/subscriptions` - +`POST /api/v1/subscriptions/:id/cancel` - ~`GET /api/v1/billing/invoices` now returns VAT. Migration notes - ENVNew: `STRIPE_API_KEY`, `STRIPE_WEBHOOK_SECRET` in Secrets Manager. - SQLMigration `2026_05_07_subscriptions_init.sql` applied. 2Runbooks for the new failure modes ### Reviewed by SRE before the first incident. Stripe webhook stalls. Dunning queue backed up. VAT API rate-limited. Failed invoice generation. Each scenario gets a runbook generated from the architecture diagram: recovery path, on-call escalation, rollback trigger. Stripe webhook stalls recovery · escalation · rollback Runbook ready Dunning queue backed up recovery · escalation · rollback Runbook ready VAT API rate-limited recovery · escalation · rollback Runbook ready Failed invoice generation recovery · escalation · rollback Runbook ready 3Observable rollout, canary first ### Behind a flag, on a slice of traffic. PAY-101 ships behind a feature flag, canary'd to a slice of FinCo's traffic. Metrics on subscription-success, dunning-trigger, and VAT-calculation are wired in before deploy. Anomaly thresholds tuned over the first two weeks of real usage. Canary · PAY-101 · production 25%of traffic Subscription success 99.2% Dunning trigger rate 0.3% VAT calc latency · p95 84ms 4Retro that compounds ### PAY-102 starts with PAY-101's lessons loaded. What worked, what slipped, what surprised us. Captured and indexed back into the knowledge base. The next epic on this product (or a comparable one) starts smarter, automatically. Worked - Figma MCP saved 3 dev-days on the plan selector. - RAG context on AC-002 caught the trial-edge bug pre-merge. - House `stripe-checkout` skill: zero rework. Slipped - Dunning email timing (AC-003): caught in QA, not unit. - Adyen credentials blocked PAY-112 by 3 days. Surprised - VAT for CH was simpler than expected (single rate). - Multi-currency display landed on day one. Indexed into the S-PRO knowledge base · PAY-102 starts smarter 5Two weeks post-release: the first audit ### Year-two projects don't slow down. They speed up. Two weeks after PAY-101 ships, Claude runs the project's first scheduled tech audit on the new code: architecture drift, unused exports, dead branches in the dunning logic, dependencies that fell behind. From here, the audit runs every two weeks across the whole codebase. Tech audit · scheduled 2026-05-21 Healthy ### PAY-101 · 14 days post-release - 0 architecture drift against the rulebook OK - 2 unused exports in `subscription.service.ts` Low - 1 dead branch in dunning retry logic Low - 3 dependencies behind: `stripe`, `zod`, `pg` Medium **Next sprint:** 4 prioritized fixes, queued in Confluence before sprint planning. Three months from now, PAY-101 still feels like the day it shipped. Common questions ## Things we get asked. Real questions from real prospects, answered straight. While AI coding assistants are incredible tools, they are not magic wands for complex software. When you scale beyond a simple prototype, AI quickly hits **context limits**, struggles with complex integrations, and gets confused managing dozens of concurrent tickets. We bring the engineering mindset required to manage context windows, token optimization, and system architecture so your project actually crosses the finish line. **Yes, it is secure.** We use enterprise-grade environments and strict data governance policies. Your proprietary code and business logic are **never used to train public AI models**. We ensure that your intellectual property remains entirely yours and completely isolated. **Absolutely.** Our AI SDLC methodology is completely *model-agnostic*. If your compliance team restricts the use of tools like Claude or OpenAI, we can route your development through secure, approved enterprise foundries or private cloud environments like **AWS Bedrock** or **MS Foundry**. **No.** There is a massive difference between fast "AI slop" and our banking-grade methodology. We don't just let AI write code unchecked; we use AI to *enhance the workflows of senior engineers*. Every line of code goes through rigorous **Agent QA** and automated testing (like Playwright) to ensure the architecture is solid, scalable, and maintainable. Unmanaged AI development can quickly snowball in cost due to poor *"tokenomics"*. Our architects structure prompts and context sharing to heavily optimize token usage. We know exactly how to leverage the technology efficiently so your project stays on budget without sacrificing quality. The AI landscape changes weekly, so we do too. We continuously benchmark, test, and integrate the latest state-of-the-art models and tools into our pipeline. Our landing page reflects our current stack, and we transparently **update our methodology every few months** to ensure you are always getting the most competitive edge possible. **Not at all.** Our approach automates the tedious execution and validation phases, which frees up our senior engineers and product owners to act as *true consultants*. By letting AI handle the heavy lifting of code generation, our human experts focus entirely on your business logic, creative problem-solving, and ensuring the product perfectly matches your vision. Traditional development often moves in quarters; **we move in days and weeks**. By automating implementation and validation, we drastically reduce time-to-market. This allows you to test ideas with focus groups and get actual products into your users' hands *exponentially faster* than the industry standard. Link copied to clipboard Language - [EN](https://s-pro.io/ai-native-sdlc) - [DE](https://s-pro.io/de/ai-native-sdlc) - [FR](https://s-pro.io/fr/sdlc-natif-ia) [Get in touch](https://s-pro.io/get-in-touch)