FAQ

Questions we are asked

Short, plain answers about how Wagenberg Technology Group works.

What does Wagenberg Technology Group do?

We help startups and small software teams get a product ready to launch or scale. We do three things: calendar and scheduling audits with fixes, launch-readiness reviews, and reviews of AI-generated data and content.

Who will I work with?

Thomas Wagenberg, the founder, scopes and leads every engagement and signs off every finding. Testing and fixes use AI-assisted engineering under his direction, and every change reaches you as a pull request your team reviews.

How does a project run?

We agree the scope in writing, work in your staging environment, file each finding as a ticket in your tracker, deliver fixes as pull requests your team reviews before merging, retest each fix, and send a written progress note every week.

Do you work on our live system?

No, not unless you grant production access in writing. Work happens in staging, and every change arrives as a pull request your team reviews before it is merged.

Where do you work?

We work remotely with teams across the United States, including teams in Cleveland and Fort Lauderdale.

How is pricing set?

Pricing depends on the scope of the project. We agree the scope in writing before work starts.

Do you put our data into AI tools?

We use AI tools only on accounts that do not train on your data. Passwords, API keys and bulk data are never pasted into AI tools. Other sensitive information may be processed only with authorization, appropriate safeguards, verified provider terms, and controlled access.

Do you offer IT support, hosting or marketing?

No. We focus on calendar and scheduling audits, launch-readiness reviews, and AI data and output review.

What does a calendar and scheduling audit check?

Availability logic, self-serve booking, time zones including daylight saving changes, calendar sync and feeds, and the automated tests around them. You get a written assessment of defects and fragile areas, then fixes as reviewed pull requests with tests for the findings you assign to us.

What happens in a launch-readiness review?

We test the product end to end for every user role, on desktop and mobile, in a staging environment. Each defect is filed with steps to reproduce, expected and actual result, and severity. We fix the defects you assign to us and retest every fix.

How do you review AI-generated data and content?

We read a sample of the records and drafted messages your AI produces against the source data, log each error, and group the recurring patterns. Then we improve the prompts, validation rules and data pipelines as reviewed pull requests, and rerun the same examples to show what changed.

What are the practical limits and risks of AI-generated output?

AI output can be wrong, and an automated step can fail without anyone noticing. The three limits we plan around are these. First, output can be wrong or out of date, so anything that reaches a user or informs a decision needs a check, by a person or by a rule in code. Second, data sent to AI tools creates exposure. We use AI tools only on accounts that do not train on your data, and passwords, API keys and bulk data are never pasted into them. Third, a silent failure goes unnoticed when nothing is logged or watched, so logging is part of the work. These describe how we plan the work. They are not measured results.

How should a company evaluate an AI implementation?

This is general guidance for comparing proposals and for reviewing an AI project that is already under way. It is not a proven method of ours. A useful evaluation answers these eight questions in writing. One, the business problem: what specific task or decision is it meant to improve, and who owns that task today. Two, measurable success criteria: what will be measured, such as time per task, error rate, cost per item or response time, and what value would count as success. Three, baseline comparison: what the task costs and produces today, measured over a fair period. Four, cost: the build, the recurring model usage and hosting, maintenance, and the staff time needed to review output. Five, data privacy: the data classes the system receives, the processor, whether the provider's current written terms allow it to store or train on that data, the retention period, and who may access it. Check the terms rather than assuming. Six, human oversight: which outputs a person must approve before use, and who is responsible for that review. Seven, reliability: what happens when the model is wrong, slow or unavailable, whether failures are logged, and how errors are caught before they reach customers. Eight, ongoing ownership: who maintains the system, who owns the code, data and accounts, and what happens if the provider changes its pricing or product. A proposal that cannot answer questions one to three is not ready to judge on cost. A proposal that cannot answer five to eight is not ready to launch.

How do we start?

Request a consultation through the contact form on this website, or email thomas@wagenbergtech.com.

If you are judging an AI feature or proposal, our guide How to evaluate an AI implementation before you hire anyone sets out eight questions to ask in writing.