BBE Marketing

We’re looking for an experienced developer to build an AI assistant that users can interact with through text messaging. The assistant will connect to our existing database, answer questions using our information, handle follow-up questions, and send personalized news updates based on users’ interests.

The experience we’re aiming for is similar to texting an assistant like Instinct or Muse, with a focused scope: answering questions using our existing database and delivering personalized news updates.
 

You’ll take ownership of the technical setup, integrations, and development, working with our team to launch an initial version. Our target is a working pilot within approximately one month, with the scope finalized together.
 

You should have strong Python/Django experience and hands-on experience integrating AI models, APIs, and databases. Experience with Twilio or similar messaging platforms is important, along with building secure account access, subscription permissions, and scheduled notifications.
 

We’re looking for someone who has built and launched practical AI applications and can make sound technical decisions, communicate clearly, and identify potential issues early. Accuracy is essential: the assistant needs to retrieve reliable information from our data and handle unclear questions appropriately.
 

When applying, please share examples of relevant applications you’ve built, explain your specific role, and describe the tools you used. Please also include your availability over the next month and your hourly rate or estimated project budget.

We're hiring full-time developer to build and maintain our Python/Flask platforms that collects data from a growing list of websites. We're looking for an engineer to own that data end to end: collecting it reliably, structuring it well, analyzing it with AI, and exposing it through APIs that our other applications depend on.

What you'll do
 

1. Scraping

• Add new sites to the scraper. Analyze each target site's structure, write parsers with BeautifulSoup4, and map the extracted data into our database models.
• Maintain existing scrapers. Diagnose and fix breakages caused by layout changes, new anti-bot measures, or changed endpoints.
• Work with our adaptive HTTP client. Our client falls back through curl_cffi → httpx → requests → hrequests. You'll tune it per site, handling headers, cookies, sessions, TLS/browser impersonation, and retries.
• Keep daily runs dependable. Add logging, alerting, and failure reporting to our scheduled jobs so problems surface quickly.

2. Database design

• Design clean, scalable schemas. Model scraped data with proper normalization, keys, constraints, and indexes, balancing data integrity against query performance.
• Manage schema changes safely. Use migrations (Alembic / Flask-Migrate) across SQLite in development and PostgreSQL in production.
• Protect data quality. Validate, normalize, and deduplicate data so that everything built downstream can rely on it.

3. AI and data analysis

• Turn raw data into insight. Analyze scraped data to find trends, anomalies, and patterns that matter to the business.
• Apply LLMs where they add value. Use models such as Claude or GPT for classification, summarization, entity extraction, and structured output from unstructured text.
• Improve how our AI reasons. Design and iterate on prompts, define structured output schemas, build evaluation sets, and measure accuracy so AI results get better over time, not just different.
   

4. APIs and integration

• Build APIs for our other applications. Design and implement well-documented REST APIs in Flask with consistent request and response schemas, versioning, pagination, and error handling.
• Secure and scale them. Implement authentication, rate limiting (Flask-Limiter), and input validation, and document endpoints with OpenAPI/Swagger.

We run an internal data platform behind a talent representation intelligence product that maps out the entertianment industry.
 

We are rebuilding the platform (legacy Symfony/Angular → Django + React) because the current system stores its most valuable data as unstructured text and can't support where the product is going. . This is not a greenfield toy and not a rescue job — it's a planned rebuild with an unusual amount of groundwork already done:

• A product & architecture document with the domain model decided: what each module means, what dies, what changes, and the conventions (append-only history, structured-at-entry, derived-values-never-facts, and more)
• An epic breakdown with dependency order and explicit definitions of done
• A decisions register — every product ruling logged, searchable, current
• Approved feature specs for the major new modules (representation history, deals/endorsements restructure, awards, drafts)
• A migration standard: raw-row archives, legacy-ID mapping, conflict review queues, rehearsed cutover — nothing silently dropped, nothing silently merged
   

Your job is to design and build within that system: propose schemas and migration plans per module (we call these build contracts — you propose, product approves, then you build), stand up the foundation (auth, field-level permissions, API-first architecture), build the cross-cutting primitives (audit log, unified sources, soft delete, lookups), and run a phased legacy migration where reconciliation counts get reviewed, not just produced.
 

How we work — read this part twice:

• The documents are the spec; the legacy code is not. Many current features are unused and several database tables are mislabeled (we've mapped this). When you hit a question about what something should do, you ask — you don't resolve it from old code. We answer questions daily, in writing, fast.
• Gates are real. Every epic starts with your proposed schema + migration plan; implementation starts after approval. Epics close when their definition-of-done closes — including a researcher completing the workflow without your help — not when the tasks are checked off.
• AI tooling is welcome and expected. We assume you'll use agents/copilots — we do. What we hire for is what the tools can't do: judgment. You verify what your tools produce against the real schema and the real data before it reaches us. "The agent said so" is not a source. (Our favorite recent bug: a generated diagram claiming a name column was an integer. The person who catches that is who we're hiring.)
• Evidence over memory. Unknowns get investigated — code usage, row counts, what breaks — and then ruled on. We don't guess.
  
  You're a fit if:
• Senior Django + React, with real ownership of at least one system end-to-end (schema through UI through deployment)
• You've done at least one legacy migration or system replacement and can talk concretely about what went wrong and what you'd do differently
• You read before you build — genuinely. Our last mismatch was a capable developer who never opened the app or the documents; the interview is designed to detect this, so if it's not you, save us both the call
• You're comfortable proposing designs to a non-engineer product owner who is deeply involved, defending them in writing, and being overruled on product grounds without sulking
• Strong written English; async-first habits; you leave a paper trail by default
• Bonus, not required: search infrastructure (Typesense/similar), data-pipeline/ETL work, having worked alongside scraper/ingestion systems, PostgreSQL depth