Available

Podcast 2 — In conversation

Speaker A: I keep seeing available used in quite different ways at work. Sometimes it means in stock, sometimes it means a person is free, sometimes it means a feature is enabled. Is it the same word doing all of those jobs?

Speaker B: It is, yes. Available is one of those adjectives that covers a broad semantic field by describing a relationship between a resource — whether that is a product, a person, a feature, or a time slot — and its accessibility or usability at a given moment. The thing is available means: you can access or use it now.

Speaker A: So the unifying idea is that whatever it is, it is reachable and usable. It is not blocked or occupied or restricted.

Speaker B: Exactly. The room is available means no one has booked it. The feature is available means it is enabled for your account. I am available on Thursday means I have no conflicting commitment. The word signals absence of obstacle — whatever would prevent access is not present.

Speaker A: What about available to versus available for? I mix those up.

Speaker B: Good distinction to nail down. Available to is followed by a person or group — this service is available to premium subscribers. Available for is followed by a purpose or activity — the room is available for booking. Both are correct but they answer different questions. To tells you who can access it; for tells you what it can be used for.

Speaker A: So I could say this feature is available to all users for free download.

Speaker B: Perfectly constructed. Both prepositions in one sentence, each doing its job correctly. The common mistake to avoid is saying available on when you mean available for — a mistake that sounds slightly off in formal writing. Available on is typically reserved for temporal expressions: available on request, available on Tuesdays.

Speaker A: What are the closest synonyms? I sometimes want to avoid repeating available in a paragraph.

Speaker B: Accessible is the most direct synonym and works in almost any context where available does. Obtainable is good when the sense is that something can be procured or acquired. At hand or on hand work in informal contexts when something is close and ready to use. Open works specifically for bookings and appointments — the slot is open. And free works when the emphasis is on being unoccupied — I am free Thursday, or the room is free all afternoon. Each synonym shifts the emphasis slightly, which is useful for varied writing.

Podcast 3 — Prompt engineering

Speaker B: Today we are working with available. This word is arguably the most important state descriptor in software development. Whether you are building a booking system, a resource manager, a feature gate, a scheduling tool, or an inventory tracker, the concept of availability is at the centre of the data model and the UI. Using available precisely in a prompt constrains the AI to build the correct state logic. Let me walk through the prompts.

Speaker A: Availability checking is something almost every application I have built has needed in some form.

Speaker B: It is a universal pattern. And the word available is the right signal to use in every prompt where that pattern is required. Here is a UI component prompt.

Speaker B: Build an availability indicator UI component that shows whether a resource is currently available or unavailable. Each resource card displays the resource name, current status as a coloured badge — green for available, red for unavailable, amber for partially available — a short status message, and a last-updated timestamp. The available state should animate with a subtle pulse. Clicking a card opens a details panel. Vanilla CSS and JavaScript, dark theme, no frameworks.

Speaker B: The three-state model — available, unavailable, and partially available — is more realistic than a binary toggle. Most real systems have an intermediate state where a resource is technically present but constrained. Specifying all three states in the prompt generates a proper state machine rather than a simple boolean display. The pulse animation on the available state gives users a live-feed feel without being distracting.

Speaker A: Partially available is the state that often breaks systems that only model two states.

Speaker B: It is. Always model the edge case. Here is a database schema.

Speaker B: Design a PostgreSQL schema for a meeting room booking system where rooms must be queried for available time slots. Include: a rooms table with id, name, capacity, floor, and features as a text array such as projector and whiteboard; a bookings table with id, room_id, booked_by as a user identifier, start_time, end_time, and status as confirmed or cancelled; a view called available_slots that for a given room and date returns time periods with no confirmed booking. Add an index on room_id and start_time in bookings. Include a check constraint that end_time is greater than start_time.

Speaker B: The available_slots view is the key design decision. Rather than leaving the application layer to compute free time by scanning booking rows, the view encapsulates that logic in the database. Any query against available_slots automatically produces only genuinely available periods. This is both more performant and more correct — you cannot accidentally display a slot as available if a conflicting booking exists.

Speaker A: Pushing the availability logic into the database rather than the application layer — I have seen that go wrong many times when it stays in the app.

Speaker B: Race conditions are the danger. The database is the right place for availability enforcement. Here is an HR scheduling application.

Speaker B: Build a staff availability management app where employees log their available working hours each week and managers can view team availability for scheduling. Employee view: a weekly grid where each day has morning, afternoon, and evening slots; click to toggle each slot as available or unavailable; submit availability for the week. Manager view: a team availability heatmap showing how many staff are available per slot across the week, colour-coded by coverage level. Vanilla JavaScript, local storage, responsive layout.

Speaker B: The team heatmap is the product insight that makes this tool genuinely useful. Individual availability records are interesting to the individual. But the manager needs to see the aggregate — which slots have sufficient coverage, which are thin. Describing it as a heatmap colour-coded by coverage level makes the AI generate a visual density display rather than a flat table, which is the appropriate format for that kind of aggregate data.

Speaker A: The heatmap turns raw availability data into a scheduling decision support tool.

Speaker B: Exactly. Visualisation is part of the product specification, not a nice-to-have. Here is a real-time dashboard prompt.

Speaker B: Build a real-time inventory availability dashboard for a warehouse management system. Each product row shows the product name, SKU, available stock quantity, reserved quantity, total quantity, and an availability status of in-stock when available is above threshold, low-stock when available is between 1 and threshold, and out-of-stock when available is zero. Allow the manager to set a low-stock threshold per product. Filter by availability status. Auto-refresh every 30 seconds. Vanilla JavaScript, local storage, dark professional UI.

Speaker B: Separating available quantity from total quantity is the most important modelling decision in that prompt. Total stock includes units reserved for pending orders. Available stock is what can actually be sold or allocated right now. Without that distinction, the available state is misleading — the system would show products as available when the remaining stock is already spoken for.

Speaker A: Available as a calculated field rather than a raw stored value. That changes how you model the whole table.

Speaker B: It does. Available should always be a derived state — computed from the current constraints — rather than a field someone sets manually. Here is a full application prompt.

Speaker B: Build a complete appointment booking platform where clients can see available slots and book sessions with service providers. Features: a public-facing booking page where clients select a service, view a calendar of available dates, select an available time slot, enter their name and email, and confirm the booking; an admin panel where providers manage their available hours by setting recurring availability patterns and blocking dates; a bookings management view showing confirmed, pending, and cancelled appointments; and automatic conflict prevention ensuring a slot cannot be booked as available if a confirmed booking already occupies it. Vanilla JavaScript, local storage, clean responsive UI.

Speaker B: Automatic conflict prevention — ensuring a slot cannot show as available if a confirmed booking exists — is the hardest technical requirement in that specification and the one most likely to be omitted if you do not name it explicitly. By stating it as a distinct requirement, you force the AI to build the availability-checking logic as a gating step in the booking confirmation flow, not as an afterthought. Available in that context is a computed truth that must be enforced at the moment of booking, not just at the moment of display.

Speaker A: Available at display time and available at booking time are two different checks, and both need to be in the system.

Speaker B: The second check is the one that prevents double bookings. Always specify it explicitly, because it is easy to omit and catastrophic to miss.