How Isaac Juracich connects interfaces, APIs, and business data

Full-stack engineering connects the interface a person uses to the services and records behind it. My public portfolio includes work on Tahari’s real estate platforms, Otherling’s commerce integrations, and Axis Campus. These are useful examples of software shaped around different operating models.

Real estate: connecting public and internal information

My work with Tahari includes listing systems, content management, internal dashboards, and investor-facing tools. A property record can appear in multiple contexts, but each context has different requirements. A public listing, an internal update, and an investor view should not automatically expose the same information.

The underlying engineering task is to make the relationships explicit. Who owns a record? Which fields belong on the public site? What happens when a listing changes? A consistent data model allows those answers to carry through the API and into the interface.

Commerce: fitting the software to the product

Otherling’s portfolio entry describes my work co-architecting a Shopify and Gadget solution, including a backend API and data flow between systems. Its focus on curated and one-of-a-kind pieces creates different needs from a conventional catalogue.

An integration should account for those differences. Identifiers, order state, availability, and the customer conversation need clear ownership. Without that, two connected systems can disagree while each looks correct in isolation.

The technical range behind the work

My background includes React, Next.js, TypeScript, Node.js, Python, FastAPI, PostgreSQL, MongoDB, and Prisma. These are tools for different parts of the product. The choice should follow the information model, the team maintaining it, and the services already in place.

Knowing both the interface and backend layers helps identify failures that cross them. A button that appears to save successfully is not enough if a request can be lost or the updated record is inaccessible to the next person in the workflow.

Start with one complete workflow

For a new system, define an end-to-end path before expanding the feature list. A lead becoming a scheduled job, or a draft listing becoming public, gives everyone a concrete behavior to review. Then define permissions, failure handling, and reporting around that path.

Read about business automation or discuss the system your team needs.