What does The Portland Company do?

The Portland Company is a software development agency that builds web apps, native iOS and Android apps, AI and LLM integrations, and blockchain applications. We work with founders, product teams, and enterprises to ship production software fast — handling architecture, design, engineering, deployment, and ongoing iteration. With two decades of experience across consumer and enterprise products, we specialize in turning ambitious ideas into shipped software using modern stacks like Next.js, Swift, Kotlin, and the latest AI tooling.

Spencer Hill is the founder of The Portland Company. He has spent two decades building software across web, mobile, AI, and blockchain, working with everyone from early-stage startups to Fortune 500 companies. Spencer leads engagements personally — clients work directly with him on architecture, technical strategy, and execution rather than being passed off to junior staff. He is hands-on with code and product, and he is the primary point of contact for every project the firm takes on.

Do you work with startups?

Yes. A significant share of our work is with early-stage startups, from pre-seed founders building a first prototype to Series A and B companies scaling their engineering capacity. We help founders move from idea to shipped MVP quickly, then continue as a long-term engineering partner as the company grows. We are comfortable working with non-technical founders, technical co-founders who need extra hands, and venture-backed teams who need senior engineering leadership without the time and cost of hiring full-time.

Do you build AI agents?

Yes. We build custom AI agents, LLM-powered features, and retrieval-augmented generation systems using the OpenAI API, Anthropic API, LangChain, and the Model Context Protocol. Our work includes tool-using agents, document understanding pipelines, voice interfaces, and agentic workflows wired into existing products. We focus heavily on evaluations, guardrails, observability, and cost control so AI features actually make it to production instead of getting stuck in proof-of-concept purgatory. Engagements range from focused prototypes to long-running AI product partnerships.

Do you build blockchain apps?

Yes. We build smart contracts and decentralized applications on Ethereum and EVM-compatible chains, written in Solidity and tested with Foundry and Hardhat. Our blockchain work includes DeFi protocols, token systems, NFT mechanics, on-chain governance, and wallet-integrated front-ends using wagmi and viem. We treat security as non-negotiable: every contract is unit-tested, fuzz-tested, and prepared for third-party audit before launch. We work with both crypto-native founders and traditional companies bringing existing products on-chain.

Where are you located?

The Portland Company is headquartered in Portland, Oregon, United States. We work remotely with clients worldwide and have shipped projects for teams across North America, Europe, and Asia. Time zone overlap is rarely an issue — we adapt our working hours to match client needs and use asynchronous communication for everything that does not strictly require a live conversation. When projects warrant it, we travel to client sites for kickoffs, workshops, or critical milestones, but the vast majority of engagements run end-to-end remotely.

Do you work with enterprises?

Yes. We work with enterprise teams that need senior engineering capacity without the overhead of expanding headcount, or that need specialized expertise in AI, blockchain, or mobile that is hard to hire for. We are comfortable with procurement processes, SOC 2 requirements, NDAs, and security reviews. Past enterprise work has spanned financial services, healthcare, retail, and media. Engagements typically run as multi-month or multi-year partnerships where we embed alongside internal teams, ship production code, and transfer knowledge as we go.

What sets The Portland Company apart?

Three things. First, you work directly with Spencer and a small senior team — there is no layer of account managers or junior engineers between you and the people writing code. Second, we have genuine breadth across web, mobile, AI, and blockchain, so we can build complete products rather than handing off pieces to other vendors. Third, we ship. We have spent twenty years optimizing the path from idea to production software, and our engagements are measured in shipped features and live users, not slide decks and roadmaps.

Choose Between Native iOS and React Native: A Decision Guide

What you'll learn

This guide gives you a decision tree, not a manifesto. We'll walk through five criteria that actually predict success — UI fidelity, team composition, performance ceilings, native API surface, and distribution strategy — score them against your specific situation, and end with a recommendation matrix. By the end you'll have a defensible answer for engineering leadership and the receipts to back it up.

Prerequisites

A draft product roadmap covering the next 4 quarters
Current team headcount by skillset (iOS, React/TS, full-stack)
A list of platform features the product depends on
Clarity on whether Android is in scope now, later, or never

Steps

1
Score platform-specific UI fidelity requirements
Inventory the UI surfaces that demand iOS-native feel: complex gestures, large-title navigation, share sheets, custom transitions, system fonts and dynamic type. Native iOS wins on polish; React Native is acceptable when 90% of screens are list-form-detail with conventional layouts.
2
Audit your team composition
Count Swift/SwiftUI engineers vs React/TypeScript engineers on hand for the next 18 months. A team with deep React expertise and no iOS hire is a stronger React Native signal than any technical criterion. Hiring senior Swift engineers in 2026 is materially harder than hiring senior React engineers.
3
Set the performance ceiling
If you ship 60fps Metal-rendered visuals, real-time audio/video processing, ARKit, on-device ML inference, or sub-100ms interaction budgets, go native. React Native's bridge (or the New Architecture's JSI) is fine for typical apps but adds tax on hot UI paths and animation-heavy screens.
4
Map required native API access
List every iOS API you'll touch: HealthKit, CallKit, WidgetKit, App Intents, Live Activities, StoreKit 2, PassKit, Push, CoreBluetooth, CarPlay. Each one in React Native means either a maintained community module, a paid module, or writing a native module yourself. Three or more 'write your own' items tips toward Swift.
5
Model distribution and release cadence
If Android is also in scope and the product is broadly cross-platform, React Native earns its keep by collapsing two codebases into one. If iOS is the strategic platform for the next 24 months and Android is best-effort or never, the cross-platform argument evaporates.
6
Stress-test with the actual product roadmap
Walk the next four quarters of planned features through both stacks. Where does each break down? A roadmap full of standard CRUD plus push and payments fits both. A roadmap full of camera pipelines, AR, or background processing pushes hard toward native.
7
Apply the recommendation matrix and commit
Score each criterion 1-5 and apply the matrix below. Pick a stack and stop relitigating. The cost of switching frameworks mid-build is 3-6 months of wasted runway — far higher than the cost of being slightly suboptimal in your initial pick.

Recommendation matrix

Criterion	Native iOS (Swift)	React Native
UI fidelity / native feel	Best-in-class	Good, with effort
Team is React-heavy	High hiring cost	Reuses existing talent
Heavy graphics / AR / on-device ML	Native ceiling	Bridge tax, limits
Many iOS-only APIs	First-party access	Module-by-module risk
Android in scope soon	Doubles cost	One codebase
Tight time-to-market, standard UI	Slower	Fastest path

Default recommendation: if iOS is your strategic platform, you have any native engineers, and your roadmap touches more than two of: AR, HealthKit, Widgets, Live Activities, complex animations, or background processing — ship Swift/SwiftUI. Otherwise, if Android is in scope and the UI is conventional, React Native (with the New Architecture) is the rational choice.

Common pitfalls

Picking React Native for "hiring," then never shipping Android. You paid the cross-platform tax for a benefit you never collected.
Choosing native "for performance" on a CRUD app. If your hottest path is a TableView, you don't have a performance problem to solve.
Underestimating native module work. Every unmaintained community module is a future migration. Audit the npm dependency graph before committing to React Native.
Believing "we'll rewrite later." Rewrites get deprioritized indefinitely. Pick the stack you'd be happy on in three years.

Next steps

Whichever way the matrix points, we build both:

Native iOS development — Swift, SwiftUI, and the full Apple platform stack.
Android development — Kotlin, Jetpack Compose, and Play Store delivery.
Talk to us about your decision.

What you'll learn

Prerequisites

Steps

Score platform-specific UI fidelity requirements

Audit your team composition

Set the performance ceiling

Map required native API access

Model distribution and release cadence

Stress-test with the actual product roadmap

Apply the recommendation matrix and commit

Recommendation matrix

Common pitfalls

Next steps