Most people who write to a small product team have never worked inside one, and that gap in experience shows up constantly in the messages we receive. A user assumes there is a large support department behind the contact form, staffed around the clock, with a ticketing system that routes every message to a specialist. The reality at instacaptions AI, like at most independent software products, is smaller and more direct: a handful of people who build the product also read the inbox, triage the bugs, and decide what gets built next. That structure has real advantages for you as a user, chiefly that your message is read by someone who actually understands the code, not a first-line agent working from a script. It also means the way you write your message matters more than you might expect, because a clear report can be acted on in minutes while a vague one can sit unresolved for weeks.
This page exists to make that relationship work better in both directions. We want to explain, honestly and specifically, what kind of information helps us help you, how we think about feature requests versus bug reports, what a reasonable response timeline looks like for a team our size, what happens to the information you send us, and how feedback actually influences what we build next. None of this is abstract customer service philosophy. It reflects how our contact channel is actually used day to day, and it is written so that the next message you send has a better chance of resulting in something fixed, answered, or shipped.
We also want to set expectations honestly rather than inflate them. A small team cannot promise instant fixes, guaranteed feature delivery, or personalized onboarding calls. What we can promise is that a real person reads every message, that we take bug reports and privacy questions seriously, and that we will tell you plainly when something is out of scope rather than string you along. That kind of honesty is, in our view, more useful to you than a polished non-answer.
What a Small Team Can and Cannot Do
A useful way to think about a small software team's support capacity is to imagine the total number of working hours available in a week and how many of those hours are already committed to building and maintaining the product itself. If the team spends most of its time writing code, fixing regressions, and keeping infrastructure running, then the hours left over for reading and responding to messages are genuinely limited. This is not a complaint, it is simply the arithmetic of running a lean operation, and it explains why response times at a small company are measured in business days rather than minutes, and why not every request results in a custom solution built just for one user.
What this means practically is that we prioritize messages that affect many people over messages that affect one person's specific workflow, unless that one person has found something that turns out to be a broader bug. A report that says a particular browser crashes when generating a caption longer than a certain length is valuable because it likely affects everyone using that browser. A request to add a very specific integration for one person's internal tool is valuable feedback but is unlikely to be built quickly, because the return on that engineering time, spread across our whole user base, is much smaller. We try to be honest about this distinction rather than pretending every request is equally actionable.
We also cannot offer certain things that larger companies with dedicated support staff can offer: live chat with instant human response, phone support, or account-specific engineering consultations. What we can offer is a genuine read of your message by someone with the authority and technical knowledge to act on it, which in many cases is more useful than a first-tier support agent who has to escalate everything anyway. Knowing which kind of help you are likely to get from a team like ours changes how you should frame your message, and framing it well is the single biggest lever you have over how quickly it gets resolved.
Writing a Bug Report That Actually Gets Fixed
The difference between a bug report that gets fixed in a day and one that sits unresolved for weeks almost always comes down to reproducibility. A developer cannot fix something they cannot see happen, and "it doesn't work" gives us nothing to work with. The single most valuable thing you can include in a bug report is a specific sequence of steps: what page you were on, what you clicked or typed, what you expected to happen, and what happened instead. If you can reproduce the issue twice using the same steps, write those steps down exactly as you performed them, because small variations, like whether you were logged in or which browser tab was active, sometimes turn out to be the actual cause.
Environment details matter more than people assume. The browser and version you are using, whether you are on a phone or a desktop, and your operating system all affect how web applications render and behave. A layout bug that appears only on an older version of Safari on an iPhone will never surface if we test only on a current desktop browser, so telling us the exact environment saves real diagnostic time. If the issue involves an error message on screen, copy the exact text rather than paraphrasing it, since error messages often contain specific codes or details that point directly at the underlying cause.
Screenshots and, where possible, short screen recordings are extremely useful, particularly for visual bugs, layout problems, or anything involving a sequence of interactions that is hard to describe in words. A ten-second screen recording showing a button not responding is often worth more than three paragraphs of description, because it removes any ambiguity about what actually happened on screen. If you are comfortable doing so, opening your browser's developer console and taking a screenshot of any red error text there can also speed up diagnosis considerably, though we never expect non-technical users to do this and a plain description is always acceptable.
One thing that genuinely slows us down is a report that bundles multiple unrelated problems into a single message with no separation between them. If you noticed three different issues, list them as three distinct numbered items rather than a single narrative paragraph, because we often need to route different issues to different parts of the codebase, and a tangled report makes it easy to miss one of the three problems entirely. Clear separation, even in an informal email, respects both your time and ours.
Feature Requests: How to Ask for Something Well
Feature requests are some of the most valuable messages we receive, because they come directly from people using the product for real work, and they often surface gaps we would not have noticed from the inside. But there is a meaningful difference between a request that describes a problem and a request that prescribes a specific solution, and the former is almost always more useful to us even though the latter feels more concrete to write. If you tell us "I need a way to save my brand voice settings so I don't have to re-enter them every time," that is a problem statement we can solve in whatever way fits our architecture best. If you instead specify exactly which dropdown menu should appear where, you may be describing a solution that does not actually fit how the rest of the interface works, and we may end up solving the underlying problem differently anyway.
It also helps enormously to explain the context behind a request rather than just the request itself. "Add bulk export" is a short sentence but it tells us little about why it matters. "I manage captions for twelve client accounts and currently have to copy each one out individually, which takes about twenty minutes every week" tells us the actual workflow, the actual pain point, and gives us a sense of how much time a fix would save. Requests framed around a real workflow, even briefly, are far more persuasive internally when we are deciding what to prioritize than requests framed as abstract feature ideas.
We read every feature request, but we do not maintain a public roadmap with committed dates, because as a small team our priorities shift based on real usage patterns, technical constraints we discover along the way, and the aggregate pattern of what people are actually asking for. If ten different people independently ask for the same capability using different words, that pattern carries far more weight internally than any single request, however well written. This is one more reason to write your request in plain, specific language rather than technical jargon: plain language is easier for us to recognize as matching a pattern from other messages, and patterns are what actually move something from an idea into a scheduled piece of work.
It is also fair for you to know that not every reasonable request gets built. Some ideas are good in isolation but conflict with the simplicity we are trying to preserve in the interface, some require infrastructure changes that are disproportionate to the benefit, and some are genuinely good ideas that are simply behind other genuinely good ideas in the queue. When we decide not to build something, we try to say so honestly rather than leaving the request in an ambiguous limbo, because a clear no is more respectful of your time than a vague maybe that never resolves.
What Happens to the Information You Send Us
When you use our contact form, the message is sent as a standard email through your own email client rather than stored in a database on our servers, which means the primary copy of your message lives in your own sent mail and in our inbox, subject to whatever retention practices apply to standard business email. We do not use the content of support messages, bug reports, or feature requests for any purpose beyond responding to you and, in aggregated and anonymized form, informing our understanding of common issues and requested features. We do not sell or share this correspondence with third parties, and we do not use the specific content of your message to build an advertising profile.
If your message includes account details, such as an email address associated with your account, we use that only to look up your account status and respond to your specific issue. If your message includes files, screenshots, or descriptions of content you generated, we treat that information as you intended it, namely as diagnostic material for the specific issue you reported, and we do not repurpose it. If a bug report happens to reveal a security vulnerability, we treat that report confidentially while we investigate and fix it, and we do not publicly disclose the details of a reported vulnerability until a fix has shipped, to avoid exposing other users to risk in the interim.
For requests specifically about privacy, data deletion, or account closure, we handle those according to the commitments described in our privacy policy, and we recommend including the email address associated with your account so we can locate your data accurately. Takedown requests concerning specific pieces of content, whether a generated caption you believe infringes on someone's rights or a page you believe contains inaccurate information, are handled with particular care, and we aim to acknowledge and resolve these within the timeframe stated on our contact page, generally faster than general feedback because these requests often have real consequences for the people involved.
Realistic Expectations for Response Time and Follow-Through
We aim to respond to messages within a couple of business days, and most straightforward questions, like how a particular feature works or why a specific behavior occurs, get answered within that window. Bug reports that require investigation sometimes take longer, not because we are ignoring them but because reproducing an issue, especially one that depends on a specific browser, device, or account state, can genuinely take time, and we would rather send you an accurate update once we understand the cause than a premature reassurance that turns out to be wrong. If a fix requires a larger change, we will tell you that directly rather than let the thread go silent.
It is worth knowing that most support and feedback interactions with a small team happen entirely by email, without a formal ticket number or status tracker, which can feel less structured than dealing with a large company but usually means the person you are corresponding with has more context and more ability to actually fix the thing you are describing. If you do not hear back within the window we describe on our contact page, a polite follow-up is entirely reasonable and is not going to annoy anyone, since messages occasionally do get missed in a small inbox, particularly during periods of high volume.
We also want to be honest that not every issue gets a satisfying resolution on the first try. Sometimes what looks like a bug turns out to be expected behavior that we have not explained well in the interface, in which case the more useful fix is often a clearer label or tooltip rather than a change in logic. Sometimes an issue is specific to a combination of browser extensions, ad blockers, or network configurations on your end that we cannot reproduce, in which case we will tell you what we tried and what we think is happening, even if we cannot offer a definitive fix. Being told clearly what we could and could not determine is, in our experience, more useful to frustrated users than silence or a canned apology.
How Feedback Actually Shapes the Roadmap
One legitimate question users have is whether writing in actually changes anything, or whether feedback forms are simply a way for companies to appear responsive without any real influence on what gets built. We can only speak to how our own process works, which is this: every message that contains a bug report or a feature suggestion is logged internally in a shared list that the whole team reviews periodically, not just the person who happened to read the email first. When the same request or the same bug appears repeatedly across independent messages, it moves up in priority, because repeated, independent signal is the clearest evidence we have that something matters to real usage patterns rather than to a single vocal user.
We also weigh feedback against what we can observe directly in aggregate, anonymized usage patterns, such as which features are used heavily and which are barely touched, and we try to reconcile the two. Sometimes a feature that generates a lot of vocal requests turns out to be used by very few people once built, and sometimes a quiet, unglamorous fix, like improving load time on a specific page, turns out to matter more to overall satisfaction than a flashy new feature that only a small number of people asked for. Feedback from the contact channel is one input among several, not the only one, but it is often the most concrete because it comes with real context about why something matters to a real workflow.
We do not promise every requested feature will ship, and we do not maintain a public voting board because in our experience those systems tend to reward whichever request can rally the most people to click a button rather than reflecting genuine underlying need. What we do commit to is reading every message carefully, being honest when something is not going to happen, and occasionally following up with people who suggested something once we have actually built it, because closing that loop, even briefly, is one of the more meaningful things a small team can do for the people who took the time to write in.
A Short, Practical Checklist Before You Hit Send
Before sending a message, it helps to ask a few quick questions that will shape how useful your report ends up being. Is your description specific enough that someone who has never seen the problem could follow the same steps and see the same result. Have you included the browser, device, and any error text exactly as it appeared. If this is a feature request, have you explained the underlying workflow or problem rather than only the feature you imagine as the solution. If this is time-sensitive, such as a payment issue or a privacy concern, have you said so clearly in the first line rather than burying it in the middle of a longer message.
None of this needs to be formal. A short, plainly written email with these elements included is far more useful than a long, polished message that omits them, and we would much rather receive five blunt sentences with a screenshot than three paragraphs of context with no specifics. Writing a good report is a skill, but it is a small one, and most of it comes down to treating the person reading your message as someone who genuinely wants to fix the problem but cannot see your screen or your account from where they sit.
Ultimately, the relationship between a small software team and the people who use its product works best when both sides treat it as a genuine exchange rather than a formality. We read what you send us, we act on it where we reasonably can, and we try to be honest about the limits of what a small team can promise. In return, a clear, specific, well-contextualized message gives us the best possible chance of turning your report into an actual fix or your suggestion into an actual feature, which is the outcome both of us actually want.