Digital services / Austin, Texas

We build search around the records you have.

We’re Yondexy, a small digital studio in Austin, Texas, United States. We offer website search, search index design, place data work and company catalogue services for people running internet projects.

Written contact address
174 Mill Street, Apt 3, Austin, Texas 28536, United States
Contact us before planning a visit; we do not publish walk-in hours.

Pricing starts with the scope. Search behaviours and result fields, source records and their condition, place relationships or company entry fields determine what needs to be priced. There is no published rate sheet. Ask for service pricing; the calculator below uses only your own budget figures.

The record comes first

A result is a route to information, not a claim about it.

A reference record describes something. An index makes a defined set of records searchable. An external search engine decides what to show in its own results. Those are different jobs, and a useful brief keeps them separate.

Here, you can ask about the structure behind a search box, the rules behind an index or the fields behind a company entry. The catalogue is inquiry-only. Nothing is added to a cart, and sending a request does not buy a listing or start a paid subscription. No checkout here. Send the brief and we will read it.

A search project can start with a supplied source file, an existing set of public pages or a record format that needs defining. Describe which one you have. We need to distinguish a source that already exists from a source that would have to be created, licensed or corrected before it can support the service you want.

The practical question is not how many results a screen can display. It is whether a person can understand why a result appeared and where its information came from. That is the basis for the service scopes below, including the parts that belong outside search itself.

01 / Query to source

Website search needs more than an input box.

A site search setup connects the words a visitor types with fields that actually exist. A name lookup is not the same as browsing by category. Exact identifiers need different handling from a broad subject query. Define those behaviours before changing the appearance of a results page.

Search index design supplies the structure underneath. It says which records are included, which fields can be searched and what happens when a source changes. Adding an attractive result row will not fix a missing field or a record that should never have been in the index.

Start with a representative query and the source it ought to reach. Then look at the awkward case: the same wording in a different record, an older version or a term with no match. Those cases expose the decisions a launch screen tends to hide. A useful website search service gives them names and an agreed treatment.

Read the search setup scope
Hands entering a query in an illustrative website search interface
Illustrative digital use. Query entry and result rows, not a deployed product or a customer result.Query / response

Separate what a record says from how it is found.

The original source may use a long title while visitors use an abbreviation. That does not automatically justify rewriting the title. A separate searchable alias can preserve the source wording while allowing a different route to it, provided the relationship is understood and the alias belongs in the agreed scope.

The same distinction applies to sorting. A result can appear first because its title matches exactly, because its date is more recent or because a visitor chose a sort order. Those are different explanations. The interface should not label all of them “best” and leave the reader to guess.

For work centred on intake rules rather than the result screen, go to the website indexing service. It deals with field mapping and update rules. The search page stays focused on what the visitor can ask and what the response means.

02 / Place to record

A place is useful when its relationship is clear.

Maps work begins with place data, not a decorative map. A location can describe a company address, a service area or the place mentioned by a source. Those meanings are not interchangeable. A place data service needs the relationship written down before coordinates become useful.

Company reference has a similar boundary. A company catalogue record is a structured entry that can carry supplied fields and a source note. It is not a review score, an endorsement or a promise that the company is currently available. Missing information must remain visibly missing rather than becoming invented certainty.

Yondexy covers map data integration as a digital scoping service. This website keeps location material in text-only records; it does not show an embedded map. The service discussion concerns place relationships and coordinate checks, not purchased placement in a third-party map service.

Read the place data scope
Text-only place fields beside a company reference panel
Illustrative place fields alongside a reference panel. The relationship is the subject; no geographic display is shown.Place / reference

Do not turn an empty field into a conclusion.

A record without an update date is not automatically current. A company without an availability field is not automatically available. The right treatment is often a short source note and an inquiry route, rather than a badge that the source cannot support.

That matters when records are combined. One source may describe a company and another may describe one of its places. Joining them by a similar name alone can produce a convincing but incorrect entry. The proposed match needs a stated basis, and uncertain relationships need a way to remain unresolved.

The company catalogue service describes entry fields and update instructions in more detail. It is for reference work and company listing inquiries, not buying reviews or purchasing a search position.

“An index needs a stated scope before it needs more entries.”

Yondexy / Working position

Service directory

Choose the part that needs work.

Each service has its own boundary. Related work can be discussed in one inquiry without pretending that every project needs all four.

Make the route from a query to its source explicit. Define searchable fields, result presentation and the filter states a visitor can understand without knowing your internal record structure.

Suggestion rows beneath a search input on a screen
Illustrative query suggestions / Search setup

Give supplied records a stated structure. A website indexing service needs inclusion rules, field definitions and an update method, not simply an instruction to collect more pages.

Index field rows and type markers on an illustrative screen
Illustrative field list / Index design

Connect place records to the data they describe. Define what a location means, where a coordinate comes from and how a change in the source affects the relationship.

A text-only place lookup with suggested records
Illustrative text-only place lookup / Map data

Present business directory records as reference entries. Keep the supplied information distinct from an inquiry action, and record how fields are supposed to be corrected or updated.

Company catalogue filters beside reference record rows
Illustrative reference filters / Company catalogue

A scope you can inspect

Make the decision visible before the interface hides it.

Look at the difference between a search field and a display field. The first determines whether a query can find the record; the second determines what the reader sees after it has been found. A source identifier may be useful for exact lookup without belonging in the most prominent line of every result. A description may be useful to read without being a sensible filter.

The worksheet below is an example of those distinctions, not a claim about a finished client project. It shows the kind of reasoning that makes a service brief testable. You can disagree with a field's role and change the scope while the decision is still inexpensive to describe.

Record roles / Illustrative worksheet

Structure, not customer data
Record identity

A stable key distinguishes a record from another record with a similar title. Decide whether the key comes from the source or needs a separate rule.

Searchable wording

Title text and approved aliases can have different matching roles. Keep the supplied wording recoverable instead of silently replacing it.

Visible description

A short explanation helps a person choose a result. Define whether it is supplied, extracted or written separately, and what happens when it is absent.

Source relationship

A source link or reference points back to supporting information. Its presence does not establish that every statement in that source has been verified.

Update instruction

A new source version can replace fields or trigger review. Those are different operations; an index needs to know which one the project expects.

Exclusion reason

A record can remain outside the searchable set because its permission or scope is unresolved. Exclusion is a record decision, not an invisible search failure.

Read the scope in both directions.

From the visitor's side, ask what someone should be able to find. From the source's side, ask what the available records can support. If those answers do not meet, expanding the interface is not the next step. The source may need work, or the requested behaviour may need a narrower definition.

This is also how adjacent services remain separate. A new company reference entry might need an index rule, but it does not automatically need place relationships. A place lookup might need searchable text, but it does not automatically need a company catalogue. The service inquiry can name one problem without committing you to a bundle.

Send a service inquiry

From inquiry to agreed work

The source sets the order of work.

Use the first message to establish the problem, not to assemble a finished specification. Tell us what people need to find and what information already exists. If a project is still an idea, say so. A service scope should not treat an uncreated source as if it were ready for implementation.

  1. Send the boundary and the source format.

    Choose the closest service and describe the records in ordinary language. A field list or a public example is enough to open the discussion. Do not send passwords, private access links or a production database through this form.

    The inquiry is a request for discussion. It is not a work order, a binding quote or permission to publish every record you mention.

  2. Clarify the missing decisions.

    The scope discussion separates existing source facts from requested behaviour. This is where inclusion rules, result fields and responsibility for source updates need to be resolved, before a pricing discussion assumes they are already settled.

    A source problem can change what should be built. If the requested filter depends on a field that has never been collected, that gap belongs in the discussion rather than in an unexplained estimate.

  3. Agree the work and its price separately.

    The number and type of records are only part of the basis. Query behaviours, field handling and update instructions affect the scope as described in each service. No calculator on this site substitutes for agreement about that work.

    Ask about timing with your inquiry. The website does not promise a start date or response window for general service requests, and sending a budget does not reserve capacity.

  4. Review against the agreed examples.

    A result should be checked against the source and the stated behaviour, including no-match cases. An index should be checked against its inclusion rules. Review has a clearer purpose when the examples are written into the scope rather than chosen after the work looks finished.

    Questions about corrections stay tied to the work Yondexy controls. External source availability and third-party search rankings are separate matters; the correction and guarantee limits explain that boundary.

A practical fit

Bring a record problem, not a ranking target.

This service fits a project that needs clearer retrieval or a better-defined reference structure. You do not need a finished schema. You do need a source you can describe and a reason someone would want to search it. An existing search tool is not a barrier; explain what it currently does and where the intended behaviour differs.

If the source is inconsistent, that is useful information, not a reason to disguise it as a clean spreadsheet. A blank date, an ambiguous company name or a duplicate record can materially affect the work. Describe the condition without uploading private material. The scope can then distinguish source preparation from the search experience itself.

Yondexy is not a route to guaranteed Google or Bing rankings, bought review scores or guaranteed placement in an external map service. Those outcomes are not controlled by an on-site search setup. Nor does a reference entry verify a company's credentials. Projects whose main requirement is one of those promises are not a fit.

For a smaller request, name the smallest boundary that solves the problem: a result field, a particular record batch or an update instruction. There is no published minimum fee to infer from the site. Pricing is requested through an inquiry, with the work described rather than guessed from a screen image.

Send a service inquiry

Planning tool / USD

Put your unit budget beside the scope.

This live estimator multiplies a record count by the lower and upper amounts you enter. It helps express your budget assumptions. It does not calculate Yondexy fees.

No operator rates or price modifiers are published here. Source condition can travel with the inquiry, but it does not silently change the amount. Leave the budget fields blank if you would rather ask for pricing without an estimate.

Your figures × your units

For search, count searchable records. For indexing, count source records. Place work uses place records; company catalogue work uses company entries. Query behaviour and field complexity still need a separate scope discussion.

Per-unit budget estimator

Visitor-budget mode

Choose the service whose records you are counting.

Searchable records. Enter a positive whole number.

Optional. Enter your own amount; zero is accepted.

Optional. Use an amount at least as high as your lower budget.

This does not apply a fee or a budget multiplier.

Your planning budget

Enter your unit budget to calculate a range. Ask us for service pricing.

Uses your figures, not Yondexy rates. Not a quote.

Send a service inquiry

A unit count is not the whole price basis.

The calculator deliberately uses one calculation: count multiplied by your per-unit amount. It cannot know whether a record has one searchable field or many, whether the same record appears in several sources or whether an update should replace an entry. Those decisions belong to the service scope, not to an invented rate formula.

Keep the count and the budget on the same basis. If you count company entries, do not enter a per-field budget and interpret the total as a batch price. If the count is provisional, explain that in the specification. The assumptions are more useful than an apparently precise total with the wrong unit underneath it.

There is no charge to calculate a planning range and no payment step after it. Choosing to include the assumptions adds context to a request; it is not acceptance of a price. You can submit a service inquiry without including any planning assumptions.

First contact

Tell us what the record needs to do.

A short description is enough to start. Name the source format and the point where the current search, index or reference entry stops being useful.

Provide an email address or a phone number so we can reply. Either works; you do not have to provide both. General service inquiries have no published response-time promise.

Keep the source safe

Do not include passwords, confidential datasets or sensitive information. Describe a private source rather than attaching access credentials. This form does not take file uploads or payment details.

Already discussing a request?

Include its inquiry number in your message so the context is clear. Do not use a second estimate as a substitute for agreeing a changed scope.

Service inquiry

Required: your name, permission to handle the inquiry and one way to reply. Sending does not place an order.

01 / Your reply details

Add either an email address or a phone number. Neither is required on its own, but we need one to answer.

Only include an address when it is relevant to the inquiry.

02 / The work you have in mind

Describe the task, the source format and the question a visitor needs answered. Public source references can go here; do not include private access links.

Record counts, field requirements or your planning budget belong here. Estimator assumptions are included only when you choose the inclusion control.

This permission concerns your inquiry. It is separate from your cookie and advertising storage choice.

No checkout. No online payment. A request is not an agreed quote.

Yondexy / United States

A small studio with a defined digital scope.

Search project support is useful when it stays close to the information being handled. Yondexy works across search, indexing, place data and company reference rather than presenting every internet task as the same service. The studio page explains the source-first approach and the distinction between a reference entry and an external search engine.

Use the contact page for a direct inquiry without the budget tool. The written contact address is 174 Mill Street, Apt 3, Austin, Texas 28536, United States. No appointment hours or walk-in availability are published; contact us before treating that address as a visit destination.